Le voci ACL (Access Control List) consentono o negano a un utente di accedere a un oggetto. Le voci ACL non proteggono l'oggetto, poiché la voce ACL non può verificare l'identità dell'utente. Una voce ACL contiene il nome utente e può specificare un nome host o un nome dominio. Ad esempio, è possibile che un utente acceda agli oggetti creando un account su un computer il cui nome host è lo stesso di un nome dominio Windows autorizzato. Utilizzare voci ACL per controllare l'accesso agli oggetti nel dominio del broker, ma non utilizzano le voci ACL per proteggere i domini del broker; utilizzare SSL o uscite di sicurezza per proteggere i canali tra componenti nel dominio del broker.
WebSphere Message Broker utilizza le voci ACL (Access Control List) per la gestione degli utenti e dei gruppi che possono modificare gli oggetti nel dominio del broker. E' possibile assegnare ad un utente o gruppo quattro diversi livelli di accesso: Controllo totale, Visualizza, Distribuisci e Modifica. Non tutti i livelli di accesso sono validi per tutti i tipi di oggetto; consultare Autorizzazioni ACL per un elenco delle autorizzazioni che possono essere applicate a ciascun tipo di oggetto e per un riepilogo delle azioni che l'utente o il gruppo può eseguire.
Al fine di ridurre il numero di voci di controllo accessi che un amministratore di broker deve creare, le autorizzazioni ACL operano in modo gerarchico. L'oggetto ConfigManangerProxy è il root della struttura ad albero che dispone di tre child: RootTopic, Subscriptions e PubSubTopology. L'oggetto PubSubTopology dispone da zero a più broker come child e ciascun broker può avere come child da zero a più gruppi di esecuzione. Quando una voce ACL viene aggiunta ad un dato oggetto, tale autorizzazione viene assegnata all'oggetto e a tutti gli oggetti ad esso sottostanti nella gerarchia, a meno che non venga sovrascritto da un'altra voce ACL.
Su z/OS, è necessario definire un segmento OVMS per gli ID utente e i gruppi, in modo da consentire a Gestione configurazione di ottenere le informazioni di ID utente e del gruppo dal database di ESM (External Security Manager).
Nel diagramma riportato di seguito è presente una gerarchia di esempio:
Nei seguenti esempi, viene illustrato il funzionamento di questa gerarchia.
Esempio 1
UserA non dispone di alcuna voce di controllo accessi. Quindi UserA non può manipolare alcun oggetto nella gerarchia o visualizzare alcuno degli oggetti definiti nella gerarchia.
Esempio 2
UserB dispone di una voce ACL che gli concede l'autorizzazione Distribuisci al gruppo di esecuzione Eg1A. Ciò assegna a tale utente l'autorizzazione Visualizza implicata per PubSubTopology e Broker1. UserB deve poter visualizzare PubSubTopology e Broker1 (ad esempio, in Message Brokers Toolkit) per potere distribuire a Eg1A.
Dal momento che UserB non dispone di alcuna voce ACL per PubSubTopology o Broker1, UserB non eredita l'accesso all'altro broker o gruppo di esecuzione nella gerarchia. In pratica, ciò significa che UserB può vedere che sul broker Broker1 è definito un altro gruppo di esecuzione, ma non ne può visualizzare alcun dettaglio (incluso il nome). Allo stesso modo, UserB può vedere che nell'ambito della topologia esiste un altro broker, ma non può vedere alcun dettaglio. UserB non ha alcun accesso a RootTopic o a Subscriptions (tabella di sottoscrizioni).
mqsicreateaclentry testcm -u UserB -a -x D -b Broker1 -e Eg1AIl comando mqsilistaclentry visualizza quindi le seguenti informazioni:
BIP1778I: userb -USER - D - Broker1/Eg1A - ExecutionGroup
Esempio 3
CMP Visualizza
RootTopic Visualizza
Subs Visualizza
Topologia Visualizza
Broker1 Totale
Eg1A Totale
Eg1B Totale
Broker2 Visualizza
Eg2A Visualizza
Eg2B Visualizza
mqsicreateaclentry testcm -u UserC -a -x V -p mqsicreateaclentry testcm -u UserC -a -x F -b Broker1Il comando mqsilistaclentry visualizza quindi le seguenti informazioni:
BIP1778I: userc - USER - V - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userc - USER - F - Broker1 - Broker
Esempio 4
CMP Totale
RootTopic Totale
Subs Totale
Topologia Totale
Broker1 Visualizza
Eg1A Visualizza
Eg1B Visualizza
Broker2 Totale
Eg2A Totale
Eg2B Totale
mqsicreateaclentry testcm -u UserD -a -x F -p mqsicreateaclentry testcm -u UserD -a -x V -b Broker1Il comando mqsilistaclentry visualizza quindi le seguenti informazioni:
BIP1778I: userd - USER - F - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userd - USER - V - Broker1 - BrokerIl seguenti comando consente di eliminare le voci ACL per UserD:
mqsideleteaclentry testcm -u UserD -a -b Broker1
Al fine di modificare le voci di controllo accessi per un oggetto, un utente deve avere l'autorizzazione totale su tale oggetto o sugli elementi parent nella gerarchia. Ciò significa che l'autorizzazione a modificare gli ACL è identica a quanto descritto in precedenza, ad eccezione del fatto che l'accesso agli ACL non può essere eliminato assegnando un'autorizzazione inferiore nella struttura ad albero; ciò è necessario in quanto altrimenti un utente sarebbe in grado di assegnare una voce Visualizza e non sarebbe poi in grado di eliminarla.
Le voci ACL possono essere gestite utilizzando l'API Proxy di Gestione configurazione Java oppure utilizzando i comandimqsicreateaclentry, mqsideleteaclentry e mqsilistaclentry.