Utilize a segurança baseada em tópico para controlar quais aplicativos no sistema de Publicação/Assinatura podem acessar informações e em quais tópicos.
Para cada tópico ao qual você deseja restringir o acesso, é possível especificar quais proprietários (IDs de usuários e grupos de IDs de usuários) podem publicar no tópico e quais proprietários podem assinar o tópico. Também é possível especificar quais proprietários podem pedir a entrega persistente de mensagens.
Qualquer proprietário pode publicar, assinar e pedir a entrega persistente de mensagens sobre qualquer tópico cujo acesso não for restringido explicitamente.
A segurança baseada em tópico é gerenciada por um Servidor de Nome de Usuário que utiliza as ACLs (Access Control Lists) que você criar para decidir quais autorizações são aplicadas.
O Servidor de Nome de Usuário no WebSphere Message Broker gerencia o conjunto de proprietários que já estão definidos na rede, em nome dos intermediários e do Configuration Manager, para uso em Publicação/Assinatura.No Windows, essa lista de usuários é obtida do domínio especificado no comando mqsicreateusernameserver.
O Servidor de Nome de Usuário é tornado conhecido ao intermediário e ao Configuration Manager especificando o gerenciador de filas do Servidor de Nome de Usuário nos comandos mqsicreatebroker e mqsicreateconfigmgr.
Os intermediários de mensagens dentro do domínio do intermediário interagem com o Servidor de Nome de Usuário para recuperar o conjunto total de usuários e grupos dos quais as Access Control Lists são criadas e em relação aos quais os pedidos de Publicação/Assinatura são validados. O Configuration Manager interage com o Servidor de Nome de Usuário para exibir os usuários e grupos de usuários nas ACLs que são criados utilizando o Editor de Hierarquia de Tópicos fornecido na Perspectiva de Administração do Intermediário do workbench.
As Access Control Lists são utilizadas para definir, para qualquer tópico e proprietário, o direito desse proprietário publicar nesse tópico ou assiná-lo ou de pedir a entrega persistente de uma publicação sobre esse tópico.
Também é possível utilizar a ACL para definir o nível de proteção de mensagem que você deseja aplicar a cada tópico.
Especifique essas definições utilizando o Editor de Hierarquia de Tópicos na Perspectiva de Administração do Intermediário do workbench.
O controle de acesso pode ser definido explicitamente para cada tópico individual. Contudo, se nenhuma ACL explícita for definida para um tópico, o controle de acesso será herdado de um tópico ancestral ou pai, conforme definido pela estrutura hierárquica da árvore de tópicos. Se nenhum tópico na hierarquia até a raiz do tópico tiver uma ACL explícita, o tópico herdará a ACL da raiz do tópico.
Qualquer proprietário definido que seja conhecido para o Servidor de Nome de Usuário pode ser associado a um tópico dessa maneira.
Não é possível associar ACLs a tópicos que incluam um ou mais caracteres curinga. Contudo, o acesso do aplicativo cliente é resolvido corretamente quando o registro de assinatura for efetuado, mesmo quando esse aplicativo especificar um caractere curinga no tópico.
Além dos grupos que você define, o WebSphere Message Broker fornece um grupo implícito, PublicGroup, ao qual os usuários pertencem automaticamente. Este grupo implícito simplifica a especificação de ACLs em uma árvore de tópico. Particularmente, este grupo é utilizado na especificação da ACL para a raiz de tópico. Observe que a configuração padrão da raiz do tópico permite operações de publicação e assinatura para o PublicGroup. Você pode exibir e alterar esta ACL utilizando o workbench, mas não pode removê-la. Ela determina as permissões padrão para toda a árvore de tópico. É possível especificar ACLs para o PublicGroup em qualquer outro lugar da árvore de tópicos, onde desejar definir permissões para todos os usuários.
Se você tiver um proprietário denominado Público definido em seu ambiente de segurança existente, você não pode utilizá-lo para segurança baseada em tópico. Se você especificar esse proprietário dentro de uma ACL, ele será igualado ao PublicGroup e, portanto, sempre permitirá acesso global.
O WebSphere Message Broker concede privilégios especiais de controle de acesso de Publicação/Assinatura a membros do grupo mqbrkrs e ao grupo global Domínio mqbrkrs correspondente, se apropriado.
Os intermediários precisam de privilégios especiais para realizar operações de publicação e assinatura internas em redes em que houver controle de acesso. Quando você cria um intermediário em uma rede dessas, é necessário especificar um ID de usuário que pertença ao grupo mqbrkrs como o ID do usuário do serviço para o intermediário. O grupo mqbrkrs recebe privilégios implícitos para que seus membros possam publicar, assinar e solicitar a entrega persistente de mensagens na raiz de tópico (""). Todos os outros tópicos herdam essas permissões. Se você tentar configurar uma ACL para o grupo mqbrkrs utilizando o workbench, essa ACL será ignorada pelo WebSphere Message Broker.
Mensagens que são utilizadas para operações de publicação e assinatura internas são publicadas através do domínio do intermediário utilizando tópicos do sistema, que começam com as cadeias "$SYS" e "$ISYS".
Não configure ACLs em tópicos que iniciem com a cadeia "$ISYS". Você não é impedido de fazer isso, mas as ACLs são ignoradas.
Qualquer usuário que possui uma ACL de segurança no nível de objeto que fornece permissão de controle total ao objeto de tópico de raiz pode definir e manipular as ACLs que definem quais proprietários podem publicar em, e assinar quais tópicos. As ACLs também podem limitar a entrega de mensagens persistentes e definir o nível de proteção de mensagem.
Opção | Descrição |
---|---|
Publish | Permite ou nega que o proprietário publique mensagens neste tópico. |
Assinar | Permite ou nega que o proprietário assine mensagens neste tópico. |
Persistente | Especifica se o proprietário pode receber mensagens persistentemente. Se o proprietário não tiver permissão, todas as mensagens serão enviadas de maneira não persistente. Cada assinatura individual indica se o assinante requer mensagens persistentes. |
Nível de QoP | Especifica o nível de proteção de mensagem que é aplicado.
Um dos seguintes quatro valores pode ser escolhido:
|
Em geral, os tópicos são organizados em uma árvore hierárquica. A ACL de um tópico pai pode ser herdada por alguns ou por todos os tópicos descendentes que não têm uma ACL explícita. Portanto, não é necessário ter uma ACL explícita associada com cada um dos tópicos. Cada tópico tem um critério de ACL que é o mesmo de seu pai. Se todos os tópicos pais até o tópico raiz não tiverem ACLs, este tópico herda a ACL do tópico raiz.
Por exemplo, na árvore de tópicos mostrada a seguir, a raiz de tópico não é mostrada mas é suposto que haja uma ACL para PublicGroup cujos membros podem publicar, assinar e receber publicações persistentes. (O símbolo "¬" significa "não".)
Herdando ACLs em uma Árvore de Tópico
Tópico | Publicadores | Assinantes | Persistente |
---|---|---|---|
A | apenas joe | todos | ninguém |
A/P | apenas joe | todos | apenas joe |
A/K | apenas joe | todos | ninguém |
A/K/M | apenas joe | todos | ninguém |
A/K/M/N | apenas mary e joe | todos | todos exceto nat |
A/B | allen, joe | HR | ninguém |
Tópicos que não são criados explicitamente pelo administrador do sistema, mas são criados dinamicamente quando um cliente publica ou assina mensagens, são tratados da mesma forma que os criados pelo administrador do sistema, mas não têm ACL definidas explicitamente. Ou seja, as ACLs para tópicos criados dinamicamente são herdadas do ancestral mais próximo na árvore de tópico que possui um critério explícito. Portanto, não é necessário definir tópicos de folhas na árvore se eles não tiverem ACLs explícitas.
Com o WebSphere Message Broker não é possível associar um critério de segurança explícito a um tópico de caractere curinga.Por exemplo, não é possível associar uma ACL com o tópico "A/+", que representa uma hierarquia de dois níveis, além de incluir "A/B", "A/K" e "A/P".
Entretanto, o WebSphere Message Broker garante mediação de acesso correta quando um aplicativo cliente assina um tópico de caractere curinga.
Por exemplo, o tópico "A/+" não tem, e não pode ter, um critério de segurança associado explicitamente a ele. Portanto, "A/+" herda sua política de "A". Qualquer usuário pode assinar "A+" porque a ACL de assinante inclui todos.
Quando uma mensagem é publicada em "A/P" ou "A/K", o intermediário a entrega para o usuário que assinou "A/+". No entanto, quando uma mensagem é publicada em "A/B", esta mensagem é entregue apenas para assinantes que estão no grupo HR.
Se o administrador do sistema alterar a ACL de assinatura de qualquer tópico que corresponda a "A/+", o intermediário reforça a ACL quando a mensagem é entregue. A assinatura de um tópico curinga tem a semântica para entregar mensagens em todos os tópicos que correspondam ao curinga e para os quais o assinante tenha autorização para receber a mensagem.
O intermediário reforça o controle de acesso através do tópico de uma mensagem a ser entregue. As mensagens são entregues somente aos clientes que não tiveram o acesso de assinatura a esse tópico negado, explicitamente ou através de herança. Como uma assinatura pode conter um caractere curinga, a correspondência real em relação ao espaço de nomes do tópico, e portanto às ACLs dos tópicos, não pode ser feita quando a assinatura é recebida. A decisão de entregar uma mensagem a um assinante é feita somente quando uma mensagem específica com um tópico está sendo processada pelo intermediário de mensagem.
Atualizações a uma ACL de tópico não tornam-se ativas até que sejam implementadas e ativadas através do domínio do intermediário do WebSphere Message Broker workbench.
Você deve ter uma ACL de segurança no nível de objeto que fornece permissão de controle total para o objeto de tópico raiz.