As entradas da ACL (Lista de Controle de Acesso) permitem ou recusam acesso de um usuário a um objeto. As entradas da ACL, no entanto, não protegem o objeto, pois a entrada da ACL não pode verificar a identidade do usuário. Uma entrada da ACL contém o nome do usuário e pode especificar um nome de host ou nome de domínio. É possível, por exemplo, que um usuário obtenha acesso aos objetos, criando uma conta em um computador que possui um nome de host que é igual a um nome de domínio do Windows autorizado. Utilize as entradas da ACL para controlar o acesso aos objetos no domínio do intermediário, mas não dependa das entradas da ACL para proteger seus domínios de intermediário; utilize SSL ou saídas de segurança para assegurar os canais entre componentes no domínio do intermediário.
O WebSphere Message Broker utiliza entradas da ACL (Lista de Controle de Acesso) para gerir quais usuários e grupos podem manipular objetos no domínio intermediário. Há quatro níveis de acesso diferentes que podem ser concedidos a um usuário ou grupo: Total, Visualização, Implementação e Edição. Nem todos os níveis de acesso são válidos para todos os tipos de objetos; consulte Permissões de ACL para obter uma lista de permissões que podem ser aplicadas a cada tipo de objeto e um resumo das ações que o usuário ou grupo pode executar.
Para reduzir o número de entradas de controle de acesso que um administrador de intermediários deve criar, as permissões da ACL se comportam de maneira hierárquica. A raiz da árvore é o objeto ConfigManangerProxy. que possui três crianças: RootTopic, Subscriptions e PubSubTopology. O objeto PubSubTopology possui zero ou mais intermediários como filhos e cada intermediário pode ter zero ou mais grupos de execução como filhos. Quando uma entrada da ACL é incluída em um objeto específico, essa permissão é concedida a esse objeto e a todos os objetos abaixo dele na hierarquia, a menos que seja substituída por outra entrada da ACL.
No z/OS, você deve definir um segmento OMVS para IDs de usuários e grupos para que um Configuration Manager obtenha informações do ID do usuário e do grupo a partir do banco de dados do ESM (External Security Manager).
O diagrama a seguir mostra uma hierarquia de exemplo:
Os exemplo a seguir mostram como esse comportamento hierárquico funciona na prática.
Exemplo 1
UserA não possui entradas de controle de acesso. Portanto, UserA não pode manipular nenhum objeto na hierarquia nem ver nenhum dos objetos definidos na hierarquia.
Exemplo 2
O UserB tem uma entrada da ACL que fornece autoridade de Implementação para o grupo de execução Eg1A. Isso fornece autoridade de Visualização implícita a PubSubTopology e Broker1. O UserB deve ser capaz de visualizar PubSubTopology e Broker1 (por exemplo, no Message Brokers Toolkit) para poder implementar no Eg1A.
Como o UserB não possui nenhuma entrada da ACL para PubSubTopology ou Broker1,o UserB não herda acesso para os outros grupos de execução ou intermediários da hierarquia. Na prática, isso significa que o UserB pode ver que há outro grupo de execução definido no intermediário Broker1, mas não pode ver nenhum detalhe (incluindo o nome do grupo de execução). De forma semelhante, UserB pode ver que existe outro intermediário na topologia, mas não pode ver nenhum dos detalhes. O UserB não tem nenhum acesso a RootTopic ou Subscriptions (a tabeka de assinaturas).
mqsicreateaclentry testcm -u UserB -a -x D -b Broker1 -e Eg1AO comando mqsilistaclentry em seguida exibe as seguintes informações:
BIP1778I: userb -USER - D - Broker1/Eg1A - ExecutionGroup
Exemplo 3
CMP Visualização
RootTopic Visualização
Subs Visualização
Topology Visualização
Broker1 Total
Eg1A Total
Eg1B Total
Broker2 Visualização
Eg2A Visualização
Eg2B Visualização
mqsicreateaclentry testcm -u UserC -a -x V -p mqsicreateaclentry testcm -u UserC -a -x F -b Broker1O comando mqsilistaclentry em seguida exibe as seguintes informações:
BIP1778I: userc - USER - V - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userc - USER - F - Broker1 - Broker
Exemplo 4
CMP Total
RootTopic Total
Subs Total
Topology Total
Broker1 Visualização
Eg1A Visualização
Eg1B Visualização
Broker2 Total
Eg2A Total
Eg2B Total
mqsicreateaclentry testcm -u UserD -a -x F -p mqsicreateaclentry testcm -u UserD -a -x V -b Broker1O comando mqsilistaclentry em seguida exibe as seguintes informações:
BIP1778I: userd - USER - F - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userd - USER - V - Broker1 - BrokerO comando a seguir pode então excluir as entradas da ACL para o UserD:
mqsideleteaclentry testcm -u UserD -a -b Broker1
Para alterar as entradas de controle de acesso para um objeto, um usuário deve ter autoridade Total sobre esse objeto ou qualquer pai na hierarquia. Isso significa que a permissão para ele mesmo alterar as ACLs da mesma forma que descrita acima, com a exceção de que o acesso às ACLs não pode ser removido concedendo uma permissão mais baixa mais abaixo na árvore; isso é necessário pois, caso contrário, um usuário seria capaz de conceder a si mesmo uma entrada de Visualização e não seria capaz de removê-la.
As entradas da ACL podem ser manipuladas utilizando a API Java do Configuration Manager Proxy ou utilizando os comandos mqsicreateaclentry, mqsideleteaclentry e mqsilistaclentry.