Utilize a segurança baseada em tópico para controlar quais aplicativos no sistema de 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 e quais proprietários podem assinar esse 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 que utiliza as ACLs (Access Control Lists) que você criar para decidir quais autorizações são aplicadas.
O no gerencia o conjunto de proprietários que já estão definidos na rede, em nome dos intermediários e do , para uso em .No , essa lista de usuários é obtida do domínio especificado no comando .
O é tornado conhecido ao intermediário e ao especificando o gerenciador de filas do nos comandos e .
Os intermediários de mensagens dentro do domínio do intermediário interagem com o 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 são validados.O interage com o para exibir os usuários e grupos de usuários nas ACLs criadas utilizando o Editor de Hierarquia de Tópicos fornecido pela do .
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 do .
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 pode ser associado a um tópico dessa maneira.
Você não pode associar ACLs com tópicos que incluem um ou mais caracteres curinga. Contudo, o acesso do aplicativo cliente é resolvido corretamente quando o registro da assinatura for feito, mesmo quando esse aplicativo especificar um caractere curinga no tópico.
Além dos grupos que você define, o 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 definiçã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 , mas não pode removê-la. Ela determina as permissões padrão para toda a árvore de tópico. Você pode especificar ACLs para o PublicGroup em qualquer outro lugar da árvore de tópico, onde você quiser 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 fornecerá acesso global.
O concede privilégios de controle de acesso de especiais a membros do grupo mqbrkrs e ao grupo global Domain mqbrkrs correspondente, se for 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, é preciso especificar um ID do usuário que pertença ao grupo mqbrkrs como o ID do usuário de serviço para o intermediário. O grupo mqbrkrs recebe privilégios implícitos para que seus membros possam publicar, assinar e pedir 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 , essa ACL será ignorada pelo .
Não configure ACLs em tópicos que iniciem com a cadeia "$ISYS". Não é impedido que você faça isto, mas elas são ignoradas.
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ópico 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 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 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. Assinar um tópico de caractere curinga tem a semântica para entregar mensagens em todos os tópicos que correspondam ao caractere curinga e para o qual 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 .É preciso ser membro do grupo mqbrops para implementar ACLs, ou um usuário ou membro de um grupo que tenha uma ACL de segurança no nível de objeto dando pelo menos permissão de implementação para o objeto do tópico raiz.
Conceitos relacionados
Tópicos
Publicadores
Assinantes
Segurança
Segurança para Recursos de Tempo de Execução
Segurança de Publicação/Assinatura
Tarefas relacionadas
Ativando a Segurança Baseada em Tópicos
Criando um
Criando Entradas de ACL
Referências relacionadas
Editor de Hierarquia de Tópicos
Editor de Consulta de Assinaturas
Avisos |
Marcas |
Downloads |
Biblioteca |
Suporte |
Feedback
![]() ![]() |
aq01203_ |