O WebSphere Message Broker utiliza ACLs (Access Control Lists) para controlar quais usuários e grupos podem manipular objetos no Configuration Manager e no Message Brokers Toolkit. Existem quatro diferentes níveis de acesso 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; a tabela abaixo descreve quais permissões podem ser aplicadas a cada tipo de objeto e resume as ações que o usuário ou grupo pode desempenhar.
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 filhos: 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 de ACL é incluída em um objeto especificado, essa permissão é concedida a esse objeto e a todos os objetos abaixo dele na hierarquia, a menos que seja substituído por outra entrada de ACL.
No z/OS, você deve definir um banco de dados OVMS
para IDs do usuário e grupos, para que um Configuration Manager
obtenha informações de ID do usuário e de grupos do banco de dados do ESM
(External Security Manager).
O diagrama a seguir mostra uma hierarquia de exemplo:
Os cenários a seguir mostram como este comportamento hierárquico funciona na prática.
Cenário 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.
Cenário 2
CMP Nenhum
RootTopic tópico raiz
Subs Nenhum
Visualização de Topologia
Visualização de Broker1
Eg1A Implementar
Eg1B Nenhum
Broker2 Nenhum
Eg2A Nenhum
Eg2B Nenhum
Observe que, como uma entrada de controle de acesso foi especificada para o grupo de execução, ela recebeu uma permissão de Visualização implícita para o intermediário pai e a topologia, caso contrário, não ficaria visível nas ferramentas. Como não existem entradas da ACL reais para este usuário para o intermediário ou topologia, no entanto, não existe nenhum acesso herdado ao outro intermediário ou grupos de execução. Na prática, isto significa que UserB pode ver que existe outro grupo de execução definido nesse intermediário, mas não pode ver nenhum dos detalhes (incluindo o nome).
De forma semelhante, UserB pode ver que existe outro intermediário na topologia, mas não pode ver nenhum dos detalhes. UserB não possui acesso a RootTopic ou à tabela de assinaturas.
Cenário 3
Visualização de CMP
Visualização de RootTopic
Visualização de Subs
Visualização de Topologia
Broker1 Completo
Eg1A Completo
Eg1B Completo
Visualização de Broker2
Visualização de Eg2A
Visualização de Eg2B
Cenário 4
CMP Completo
RootTopic tópico raiz
Subs Completo
Topologia Completo
Visualização de Broker1
Visualização de Eg1A
Visualização d Eg1B
Broker2 Completo
Eg2A Completo
Eg2B Completo
Observe que, neste exemplo, sem a entrada de Visualização para Broker1, o usuário teria controle total. Esta utilização de entradas de Visualização é útil porque permite que os usuários geralmente tenham controle total sobre um determinado objeto para reduzir seu acesso temporariamente, para evitar exclusão ou implementação acidental. Se o usuário precisar de controle total do objeto, a remoção da entrada de Visualização restaurará o controle total, para que ele possa desempenhar as operações necessárias, em seguida, restaurará a entrada de Visualização.
Para alterar as entradas de controle de acesso para um objeto, um usuário deve ter controle total sobre esse objeto ou qualquer pai na hierarquia. Isto significa que a permissão para alterar as próprias ACLs funciona de forma semelhante à descrita acima, com exceção de que o acesso às ACLs não pode ser removido concedendo uma permissão inferior mais abaixo na árvore; isto é necessário porque, de outra maneira, um usuário poderia conceder a si próprio 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.
Objeto | Permissão | Direitos |
---|---|---|
Topologia | Controle Total |
|
Visualizar |
|
|
Intermediário | Controle Total |
|
Implementar |
|
|
Visualizar |
|
|
Grupo de Execução | Controle Total |
|
Implementar |
|
|
Visualizar |
|
|
Tópico Raiz | Controle Total |
|
Implementar |
|
|
Editar |
|
|
Visualizar |
|
|
Assinatura | Controle Total |
|
Visualizar |
|