Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Integrazione dei broker ActiveMQ con LDAP

Puoi accedere ai tuoi broker ActiveMQ utilizzando i seguenti protocolli con enabled: TLS

Amazon MQ offre una scelta tra l'autenticazione nativa di ActiveMQ LDAP e l'autenticazione e l'autorizzazione per gestire le autorizzazioni degli utenti. 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.

Integrazione LDAP con ActiveMQ

Puoi autenticare gli utenti di Amazon MQ tramite le credenziali memorizzate nel tuo server Lightweight Directory Access Protocol (LDAP). È 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 IAM credenziali e non sono integrate con. LDAP

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

Amazon MQ fornisce LDAP supporto tramite il plug-in Apache ActiveMQJAAS. Qualsiasi LDAP server, ad esempio Microsoft Active Directory o OpenLDAP, supportato dal plug-in è supportato anche da Amazon MQ. Per ulteriori informazioni sul plugin, consultare la sezione Sicurezza della documentazione di Active MQ.

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

Prerequisiti

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

L'account di servizio è un account nel tuo LDAP server, che ha accesso per avviare una connessione. È un LDAP requisito standard e devi fornire le credenziali dell'account di servizio una sola volta. Dopo la configurazione della connessione, tutte le future connessioni client vengono autenticate tramite il LDAP server. 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, è necessario uno specifico Directory Information Tree DIT () sul server. LDAP Per un ldif file di esempio che mostra chiaramente questa struttura, vedere Importare il seguente LDIF file nel LDAP server nella sezione Sicurezza della documentazione di ActiveMQ.

Guida introduttiva con LDAP

Per iniziare, accedi alla console Amazon MQ e scegli LDAPl'autenticazione e l'autorizzazione quando crei un nuovo Amazon MQ o modifichi un'istanza broker esistente.

Fornire le informazioni seguenti sull'account di servizio:

L'immagine seguente evidenzia dove fornire questi dettagli.

Nella sezione di configurazione dell'LDAPaccesso, fornisci le seguenti informazioni richieste:

L'immagine seguente evidenzia dove specificare questi dettagli.

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

L'immagine seguente evidenzia dove specificare queste impostazioni opzionali.

Come funziona LDAP l'integrazione

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 del LDAP server.

La base utenti fornita al broker ActiveMQ deve puntare al nodo in cui DIT gli utenti sono archiviati nel server. LDAP Ad esempio, se utilizzi AWS Managed Microsoft AD e disponi dei componenti del dominio e corpexample, all'interno di questicom, disponi di unità corp organizzativeUsers, utilizzerai quanto segue come base di utenti:

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

Il broker ActiveMQ cercherà gli utenti in questa posizione per autenticare DIT le richieste di connessione dei client al 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, vedere LDAPCached Authorization Module.

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

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 delle DIT quali 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 corpexample, ecom, dovresti 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ò significherebbe che la base di ricerca delle code, che fornisce informazioni di autorizzazione per destinazioni di tipo queue, avrebbe la seguente posizione all'interno dell'utente: 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 troverebbero allo stesso livello in: 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

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, specifica 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.

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).