Permissões de ACL

O WebSphere Event 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.

Início da mudançaNo 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).Fim da mudança

O diagrama a seguir mostra uma hierarquia de exemplo:

Este diagrama mostra uma hierarquia de exemplo. A raiz é CMP, que possui três filhos: RootTopic, Subscriptions e PubSubTopology. PubSubTopology possui dois filhos: Broker1 e Broker2. Cada intermediário possui dois filhos: Eg1A e Eg1B.

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

UserB possui uma entrada de Implementação para Eg1A. Portanto, UserB possui as seguintes permissões:

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

UserC possui uma entrada de Visualização para o Configuration Manager Proxy (CMP) e uma entrada de controle Total para Broker1. Portanto, UserC possui as seguintes permissões:

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

UserD possui uma entrada de controle Total para o CMP e uma entrada de Visualização para Broker1. Portanto, UserD possui as seguintes permissões:

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.

A tabela a seguir explica as ações que podem ser desempenhadas por um usuário com uma permissão especificada:
Objeto Permissão Direitos
Topologia Controle Total
  • Criar e excluir intermediários
  • Criar e excluir coletivos.
  • Incluir e remover intermediários de coletivos.
  • Criar e excluir conexões.
  • Implementar topologia.
  • Todos os direitos de permissão de Visualizar topologia
Visualizar
  • Visualizar a configuração da topologia e os subcomponentes gerenciados.
Intermediário Controle Total
  • Criar e excluir grupos de execução.
  • Editar todas as propriedades do intermediário.
  • Todos os direitos de permissão de Implementar intermediário.
  • Todos os direitos de permissão de Controle total de grupos de execução para grupos de execução contidos.
  • Todos os direitos de permissão de Visualizar intermediário.
Implementar
  • Implementar a configuração do intermediário.
  • Todos os direitos de permissão de Visualizar intermediário.
Visualizar
  • Visualizar a configuração do intermediário e os subcomponentes gerenciados.
  • Acesso de visualização implícita à Topologia.
Grupo de Execução Controle Total
  • Editar todas as propriedades do grupo de execução.
  • Iniciar e parar grupos de execução.
  • Todos os direitos de permissão de Implementar grupo de execução.
  • Todos os direitos de permissão de Visualizar grupo de execução.
Implementar
  • Implementar a configuração do grupo de execução.
  • Iniciar e parar fluxos de mensagens designados.
  • Iniciar e parar rastreio.
  • Todos os direitos de permissão de Visualizar grupo de execução.
Visualizar
  • Visualizar a configuração do grupo de execução e os subcomponentes gerenciados.
  • Acesso de Visualização implícita ao intermediário pai e à topologia.
Tópico Raiz Controle Total
  • Editar "Access Control List de Tópicos".
  • Todas as permissões de Implementar tópico raiz.
  • Todas as permissões de Editar tópico raiz.
  • Todas as permissões de Visualizar tópico raiz.
Implementar
  • Implementar toda a configuração do tópico.
  • Todas as permissões de Visualizar tópico raiz.
Editar
  • Criar e excluir tópicos filhos.
  • Todas as permissões de Visualizar tópico raiz.
Visualizar
  • Visualizar todos os tópicos (incluindo tópicos filhos) e os subcomponentes gerenciados.
Assinatura Controle Total
  • Excluir qualquer assinatura.
  • Todas as permissões de "Visualizar" assinatura.
Visualizar
  • Visualizar ou consultar todas as assinaturas e subcomponentes gerenciados.
Conceitos relacionados
Segurança para Recursos de Tempo de Execução
Segurança Baseada em Tópico
Tarefas relacionadas
Configurando a Segurança no Domínio do Intermediário
Ativando a Segurança Baseada em Tópicos
Cancelando uma Implementação em Andamento
Incluindo um Novo Tópico
Referências relacionadas
Comando mqsicreateaclentry
Comando mqsideleteaclentry
Comando mqsilistaclentry
Atualizações da ACL
Notices | Trademarks | Downloads | Library | Support | Feedback
Copyright IBM Corporation 1999, 2006 Last updated: 5월 25, 2006
ap12520_