Integrazione dei broker ActiveMQ con LDAP

Importante

L'integrazione LDAP non è supportata per i broker RabbitMQ.

È possibile accedere ai broker ActiveMQ utilizzando i seguenti protocolli con TLS abilitato:

• AMQP

• MQTT

• MQTT tramite WebSocket

• OpenWire

• STOMP

• STOMP tramite WebSocket

Amazon MQ offre una scelta tra l'autenticazione nativa ActiveMQ e l'autenticazione LDAP e l'autorizzazione per gestire le autorizzazioni utente. Per informazioni relative alle limitazioni correlate a nomi utente e password ActiveMQ, consulta Utenti.

Per autorizzare gli utenti e i gruppi ActiveMQ a utilizzare code e argomenti, è necessario modificare la configurazione del broker. Amazon MQ utilizza il plugin di autenticazione semplice di ActiveMQ per limitare la lettura e la scrittura alle destinazioni. Per ulteriori informazioni ed esempi, consulta Configurare sempre una mappa di autorizzazione e authorizationEntry.

Nota

Attualmente, Amazon MQ non supporta l'autenticazione dei certificati client.

Integrazione di LDAP con ActiveMQ

È possibile autenticare gli utenti Amazon MQ tramite le credenziali memorizzate nel server LDAP (Lightweight Directory Access Protocol). È inoltre possibile aggiungere, eliminare e modificare gli utenti Amazon MQ e assegnare autorizzazioni ad argomenti e code attraverso di esso. Le operazioni di gestione come la creazione, l'aggiornamento e l'eliminazione dei broker richiedono ancora credenziali IAM e non sono integrate con LDAP.

I clienti che desiderano semplificare e centralizzare l'autenticazione e l'autorizzazione del broker Amazon MQ utilizzando un server LDAP possono utilizzare questa funzione. Mantenere tutte le credenziali utente nel server LDAP consente di risparmiare tempo e fatica fornendo una posizione centrale per l'archiviazione e la gestione di tali credenziali.

Amazon MQ fornisce supporto LDAP utilizzando il plugin Apache ActiveMQ JAAS. Qualsiasi server LDAP, ad esempio Microsoft Active Directory od OpenLDAP supportato dal plugin, è supportato anche da Amazon MQ. Per ulteriori informazioni sul plugin, consultare la sezione Sicurezza della documentazione di Active MQ.

Oltre agli utenti, è possibile specificare l'accesso agli argomenti e alle code per un gruppo specifico o un utente tramite il server LDAP. A tale scopo, creare voci che rappresentano argomenti e code nel server LDAP e quindi assegnare autorizzazioni a un utente LDAP specifico o a un gruppo. È quindi possibile configurare i broker per recuperare i dati di autorizzazione dal server LDAP.

Prerequisiti

Prima di aggiungere il supporto LDAP a un broker Amazon MQ nuovo o esistente, occorre configurare un account di servizio. Questo account di servizio è necessario per avviare una connessione a un server LDAP e deve disporre delle autorizzazioni corrette per effettuare questa connessione. Questo account di servizio configurerà l'autenticazione LDAP per il broker. Eventuali connessioni client successive verranno autenticate tramite la stessa connessione.

Un account del servizio è un account nel server LDAP che ha accesso per avviare una connessione. Si tratta di un requisito LDAP standard ed è necessario fornire le credenziali dell'account di servizio una sola volta. Dopo aver configurato la connessione, tutte le future connessioni client vengono autenticate tramite il server LDAP. Le credenziali dell'account di servizio sono memorizzate in modo sicuro in un formato crittografato, accessibile solo ad Amazon MQ.

Per l'integrazione con ActiveMQ, sul server LDAP è necessario disporre di una specifica struttura DIT (Directory Information Tree). Per un esempio di file ldif che mostra chiaramente questa struttura, consultare Importazione del seguente file LDIF nel server LDAP nella sezione Sicurezza della documentazione di ActiveMQ.

Nozioni di base su LDAP

Per iniziare, accedere alla console Amazon MQ e scegliere LDAP authentication and authorization (Autenticazione e autorizzazione LDAP) durante la creazione di una nuova istanza del broker Amazon MQ o la modifica di un'istanza esistente.

Fornire le informazioni seguenti sull'account di servizio:

• Fully qualified domain name (Nome di dominio completo) Posizione del server LDAP in cui devono essere emesse le richieste di autenticazione e autorizzazione.

  Nota

  Il nome di dominio completo del server LDAP fornito non deve includere il protocollo o il numero di porta. Amazon MQ antepone il nome di dominio completo con il protocollo ldaps, a cui aggiungerà il numero di porta 636.

  Ad esempio, se si specifica il seguente dominio completo example.com, Amazon MQ accederà al server LDAP utilizzando l'URL ldaps://example.com:636.

  Affinché l'host del broker sia in grado di comunicare correttamente con il server LDAP, il nome di dominio completo deve essere risolvibile pubblicamente. Per mantenere il server LDAP privato e sicuro, limitare il traffico in ingresso nelle regole in entrata del server per consentire solo il traffico originato dall'interno del VPC del broker.

• Service account username (Nome utente dell'account del servizio) Il nome distinto dell'utente che verrà utilizzato per eseguire l'associazione iniziale al server LDAP.

• Service account password (Password dell'account del servizio) La password dell'utente che esegue l'associazione iniziale.

L'immagine seguente evidenzia dove fornire questi dettagli.

Nella sezione LDAP login configuration (Configurazione dell'accesso con LDAP), fornire le informazioni obbligatorie seguenti:

• User Base (Base utenti) Nome distinto del nodo nella struttura DIT (Directory Information Tree) che verrà cercato per gli utenti.

• User Search Matching (Corrispondenza ricerca utente) Filtro di ricerca LDAP che verrà utilizzato per trovare gli utenti all'interno di userBase. Il nome utente del client viene sostituito nel placeholder {0} nel filtro di ricerca. Per ulteriori informazioni, consulta Autenticazione e Autorizzazione.

• Role Base (Base di ruoli) Nome distinto del nodo nel DIT in cui verranno cercati i ruoli. I ruoli possono essere configurati come voci esplicite del gruppo LDAP nella directory. Una voce di ruolo tipica può essere costituita da un attributo per il nome del ruolo, ad esempio nome comune (NC) e un altro attributo, come member, con valori che rappresentano i nomi distinti o i nomi utente degli utenti appartenenti al gruppo di ruoli. Ad esempio, data l'unità organizzativa, group, è possibile fornire il nome distinto seguente ou=group,dc=example,dc=com.

• Role Search Matching (Corrispondenza ricerca ruolo) Filtro di ricerca LDAP che verrà utilizzato per trovare i ruoli all'interno di roleBase. Il nome distinto dell'utente abbinato da userSearchMatching sarà sostituito nel placeholder {0} nel filtro di ricerca. Il nome utente del cliente verrà sostituito al posto del placeholder {1}. Ad esempio, se le voci di ruolo nella directory includono un attributo denominato member, contenente i nomi utente per tutti gli utenti in tale ruolo, è possibile fornire il seguente filtro di ricerca: (member:=uid={1}).

L'immagine seguente evidenzia dove specificare questi dettagli.

Nella sezione Optional settings (Impostazioni opzionali), è possibile fornire le informazioni facoltative seguenti:

• User Role Name (Nome del ruolo dell'utente) Nome dell'attributo LDAP nella voce di directory dell'utente per l'appartenenza al gruppo dell'utente. In alcuni casi, i ruoli utente possono essere identificati dal valore di un attributo nella voce di directory dell'utente. L'opzione userRoleName consente di fornire il nome di questo attributo. Ad esempio, consideriamo la seguente voce utente:

  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

  Per fornire il corretto userRoleName per l'esempio precedente, è necessario specificare l'attributo memberOf. Se l'autenticazione viene completata correttamente, l'utente viene assegnato al ruolo role1.

• Role Name (Nome del ruolo) Attributo del nome del gruppo in una voce del ruolo il cui valore è il nome di tale ruolo. Ad esempio, è possibile specificare cn per il nome comune di una voce del gruppo. Se l'autenticazione ha esito positivo, all'utente viene assegnato il valore dell'attributo cn per ogni voce di ruolo di cui è membro.

• User Search Subtree (Sottostruttura di ricerca utente) Definisce l'ambito per la query di ricerca utente LDAP. Se true, l'ambito è impostato per cercare l'intera sottostruttura sotto il nodo definito da userBase.

• Role Search Subtree (Sottostruttura di ricerca ruolo) Definisce l'ambito per la query di ricerca ruolo LDAP. Se true, l'ambito è impostato per cercare l'intera sottostruttura sotto il nodo definito da roleBase.

L'immagine seguente evidenzia dove specificare queste impostazioni opzionali.

Come funziona l'integrazione LDAP

Si può pensare all'integrazione in due categorie principali: la struttura per l'autenticazione e la struttura per l'autorizzazione.

Autenticazione

Per l'autenticazione, le credenziali client devono essere valide. Queste credenziali vengono convalidate rispetto agli utenti della base utenti nel server LDAP.

La base utenti fornita alil broker ActiveMQ deve puntare al nodo nel DIT in cui gli utenti sono archiviati nel server LDAP. Ad esempio, se si sta utilizzando AWS Managed Microsoft AD e si dispone dei componenti di dominio corp, example e com, e all'interno di essi sono presenti le unità organizzative corp e Users, come base utente è necessario utilizzare quanto segue:

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

il broker ActiveMQ cercherà gli utenti in questa posizione nel DIT al fine di autenticare le richieste di connessione client alil broker.

Poiché il codice sorgente ActiveMQ codifica hardcode il nome dell'attributo per gli utenti in uid, è necessario assicurarsi che ogni utente abbia questo attributo impostato. Per semplicità, è possibile utilizzare il nome utente della connessione. Per ulteriori informazioni, consultare il codice sorgente activemq e Configurazione delle mappature dell'ID in utenti Active Directory e computer per Windows Server 2016 (e versioni successive).

Per abilitare l'accesso alla console ActiveMQ per utenti specifici, assicurarsi che appartengano al gruppo amazonmq-console-admins.

Autorizzazione

Per l'autorizzazione, le basi di ricerca delle autorizzazioni sono specificate nella configurazione del broker. L'autorizzazione viene eseguita in base alla destinazione (o carattere jolly, set di destinazione) tramite l'elemento cachedLdapAuthorizationMap, che si trova nel file di configurazione activemq.xml. Per ulteriori informazioni, consultare Modulo di autorizzazione LDAP memorizzato nella cache.

Nota

Per poter utilizzare l'elemento cachedLDAPAuthorizationMap nel file di configurazione del broker activemq.xml, è necessario selezionare l'opzione LDAP Authentication and Authorization (Autenticazione e autorizzazione LDAP) durante la creazione di una configurazione tramite AWS Management Console, o impostare la proprietà authenticationStrategy su LDAP durante la creazione di una nuova configurazione utilizzando l'API Amazon MQ.

Occorre fornire i seguenti tre attributi come parte dell'elemento cachedLDAPAuthorizationMap:

• queueSearchBase

• topicSearchBase

• tempSearchBase

Importante

Per evitare che le informazioni sensibili vengano inserite direttamente nel file di configurazione del broker, Amazon MQ blocca l'utilizzo dei seguenti attributi in cachedLdapAuthorizationMap:

• connectionURL

• connectionUsername

• connectionPassword

Quando crei un broker, Amazon MQ sostituisce i valori forniti tramite la AWS Management Console, o nella proprietà ldapServerMetadata della richiesta API, per gli attributi di cui sopra.

Di seguito è mostrato un esempio funzionante di 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> 

Questi valori identificano le posizioni all'interno del DIT in cui sono specificate le autorizzazioni per ogni tipo di destinazione. Quindi, per l'esempio precedente con AWS Managed Microsoft AD, utilizzando gli stessi componenti di dominio di corp, example ecom, è necessario specificare un'unità organizzativa denominata destination per contenere tutti i tipi di destinazione. All'interno di quell'unità organizzativa, occorre crearne uno per le destinazioni queues, uno per topics e uno per temp.

Ciò significa che la base di ricerca della coda, che fornisce informazioni di autorizzazione per le destinazioni della coda dei tipi, avrebbe la seguente posizione nel DIT:

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

Analogamente, le regole di autorizzazione per gli argomenti e le destinazioni temporanee si trovano allo stesso livello nel 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
            

All'interno dell'unità organizzativa per ogni tipo di destinazione (coda, argomento, temp), è possibile specificare un carattere jolly o un nome di destinazione specifico. Ad esempio, per fornire una regola di autorizzazione per tutte le code che iniziano con il prefisso DEMO.EVENTS.$., è possibile creare la seguente unità organizzativa:

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

Nota

L'unità organizzativa DEMO.EVENTS.$ è all'interno dell'unità organizzativa Queue.

Per altre informazioni sui caratteri jolly in ActiveMQ, fare riferimento ai Caratteri jolly

Per fornire regole di autorizzazione per code specifiche, ad esempio DEMO.MYQUEUE, specificare qualcosa di simile al seguente:

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

Gruppi di sicurezza

All'interno di ogni unità organizzativa che rappresenta una destinazione o un carattere jolly, è necessario creare tre gruppi di sicurezza. Come per tutte le autorizzazioni in ActiveMQ, si tratta di autorizzazioni di lettura/scrittura/amministratore. Per ulteriori informazioni sulle operazioni di ciascuna utente, consultare Sicurezza nella documentazione di ActiveMQ.

È necessario assegnare un nome a questi gruppi di sicurezza read, write e admin. All'interno di ciascuno di questi gruppi di sicurezza è possibile aggiungere utenti o gruppi, che avranno quindi l'autorizzazione per eseguire le azioni associate. Questi gruppi di sicurezza sono necessari per ogni set di destinazione jolly o singola destinazione.

Nota

Quando si crea il gruppo di amministrazione, si verificherà un conflitto con il nome del gruppo. Questo conflitto si verifica perché le regole legacy a Windows 2000 non consentono ai gruppi di condividere lo stesso nome, anche se i gruppi si trovano in posizioni diverse del DIT. Il valore nella casella di testo Pre-Windows 2000 non ha alcun impatto sulla configurazione, ma deve essere univoco a livello globale. Per evitare questo conflitto, è possibile aggiungere un suffisso uuid a ciascun gruppo admin.

L'aggiunta di un utente al gruppo di sicurezza admin per una determinata destinazione consentirà all'utente di creare ed eliminare tale argomento. Aggiungendoli al gruppo di sicurezza read consentirà loro di leggere dalla destinazione mentre aggiungerli al gruppo di sicurezza write consentirà loro di scrivere nella destinazione.

Oltre ad aggiungere singoli utenti alle autorizzazioni dei gruppi di sicurezza, è anche possibile aggiungere interi gruppi. Tuttavia, poiché ActiveMQ di nuovo specifica a livello di codice i nomi degli attributi per i gruppi, è necessario assicurarsi che il gruppo che si desidera aggiungere abbia la classe dell'oggetto groupOfNames, come mostrato nel codice sorgente activemq.

Per fare ciò, seguire lo stesso processo di uid per gli utenti. Consultare Configurazione delle mappature dell'ID in utenti Active Directory e computer per Windows Server 2016 (e versioni successive).