Os conjuntos de políticas e as ligações definem
e configuram os requisitos de WS-Security e WS-RM,
suportados pelo WebSphere Message Broker, para os nós SOAPInput, SOAPReply, SOAPRequest, SOAPAsyncRequest e SOAPAsyncResponse.
Um conjunto de políticas é um contêiner para os tipos de políticas WS-Security e
WS-RM.
Uma ligação de conjunto de política está associada a um conjunto de política e contém
informações que são específicas para o ambiente e a plataforma, tais como informações
sobre chaves.
Utilize conjuntos de política e ligações
para definir os seguintes itens para ambas as mensagens SOAP de pedido e resposta:
- Autenticação para os seguintes tokens:
- Tokens de nome de usuário (exige um perfil de segurança para especificar o provedor de segurança externo)
- Certificados X.509 (exige o keystore e o armazenamento confiável do broker ou um perfil de segurança para especificar o provedor de segurança externo)
- Asserções da SAML, utilizando SAML 1.1 ou 2.0 de passagem (exige um perfil de segurança para especificar o provedor de segurança externo)
- Tokens LTPA, que usam a passagem LTPA (requerem um perfil de segurança para especificar o provedor de segurança externo)
- Criptografia assimétrica (confidencialidade) utilizando certificados X.509 (exige o keystore e o armazenamento confiável do broker)
- Criptografia simétrica (confidencialidade) utilizando tokens Kerberos (exige que o host seja configurado para Kerberos)
- Assinatura assimétrica (integridade) (exige o keystore e o armazenamento confiável do broker)
Todo o corpo da mensagem SOAP ou partes específicas do cabeçalho e do corpo da mensagem SOAP podem ser criptografados e assinados.
Você administra conjuntos de políticas e ligações a partir do WebSphere Message Broker Explorer, que pode incluir, excluir,
exibir e editar conjuntos de políticas e ligações. Quaisquer alterações nas ligações ou conjuntos de políticas do kit de ferramentas são salvas diretamente no intermediário associado.
Você deve interromper e reiniciar o fluxo de mensagens para que as novas informações de configuração sejam efetivadas.
Você também pode exportar e importar conjuntos de políticas e ligações a partir de um intermediário.
Os conjuntos de políticas e suas ligações associadas devem ser salvos e restaurados
juntos.
Os conjuntos de políticas estão associados a um fluxo de mensagens, um nó ou ambos no editor de
Archive do Intermediário. Para conveniência, é possível especificar configurações para provedor e consumidor no nível do fluxo de mensagens. A configuração do provedor se aplica a todos os nós SOAPInput e SOAPReply do fluxo de mensagens. A configuração de consumidor aplica-se a todos os nós SOAPRequest, SOAPAsyncRequest e SOAPAsyncResponse. Designações de conjunto de política e ligação individuais podem ser aplicadas no nível do nó
no editor de Archive do Intermediário e elas têm precedência sobre as configurações de
provedor e consumidor no nível do fluxo. A configuração padrão é nenhum, o que significa que nenhum conjunto de política e ligação devem ser utilizados.
Vários nós no mesmo fluxo de mensagens podem ser referir ao mesmo conjunto de política
e ligações. É responsabilidade do administrador
assegurar que os conjuntos de políticas necessários estejam disponíveis para o broker no tempo de execução. Um erro
é relatado se o intermediário não pode localizar o conjunto de política ou ligações associadas.
O restante deste tópico descreve alguns dos termos que você encontrará ao
configurar conjuntos de políticas e ligações.
Conjunto de Política e Ligações Padrão
Quando
um intermediário é criado, um conjunto de políticas e ligações padrão são criados
chamados WSS10Default. Esse padrão contém uma política de segurança limitada que especifica que um token de Username está presente em mensagens de pedido (entrada) para nós de SOAPInput no fluxo de mensagens associado. Um conjunto de políticas padrão do WS-RM
chamado WSRMDefault também é criado.
A ligação do conjunto de políticas
padrão se refere ao conjunto de políticas padrão WSS10Default, mas não a WSRMDefault.
Elas não são editáveis.
Nós de Consumidor e Provedor
Os nós
são consumidores ou provedores.
- Nós de Consumidor
- SOAPRequest
- SOAPAsyncRequest
- SOAPAsyncResponse
- Nós de Provedor
-
Pedido e Resposta
Pedido e resposta é um MEP (Padrão de Troca de Mensagens). Ele descreve um cliente que
envia uma mensagem de Pedido SOAP para um servidor de serviço da Web, que por sua vez envia
uma mensagem SOAP de Resposta de volta ao cliente. A mensagem de Pedido é sempre
a mensagem SOAP do cliente para o servidor e a mensagem de Resposta é
sempre a resposta da mensagem SOAP do servidor para o cliente. A tabela a seguir descreve esse padrão em relação aos nós SOAP do
WebSphere Message Broker:
Nó |
Ponto de Vista do Intermediário |
Pedido |
Resposta |
SOAPInput |
Entrada da mensagem SOAP |
Mensagem de Entrada |
Não se aplica |
SOAPReply |
Saída da mensagem SOAP |
Não aplicável |
Mensagem de Saída |
SOAPRequest |
Menagem de saída SOAP seguida por uma mensagem de entrada SOAP |
Mensagem de Saída |
Mensagem de Entrada |
SOAPAsyncRequest |
Saída da mensagem SOAP |
Mensagem de Saída |
Não se aplica |
SOAPAsyncResponse |
Entrada da mensagem SOAP |
Não aplicável |
Mensagem de Entrada |
Iniciador e Destinatário
Iniciador e Destinatário são funções definidas na troca de mensagens SOAP.
- Iniciador
- A função que envia a mensagem inicial em uma troca de mensagens.
- Destinatário
- A função de destino para processar a mensagem inicial em uma troca de mensagens.
A tabela a seguir descreve essas funções em relação
aos nós SOAP:
Nó |
Ponto de Vista do Intermediário |
Iniciador |
Destinatário |
SOAPInput |
Entrada da mensagem SOAP |
Cliente externo enviando mensagem SOAP para o intermediário. |
Nó SOAPInput |
SOAPReply |
Saída da mensagem SOAP |
Cliente externo que enviou a mensagem SOAP original para o intermediário. |
Nó SOAPReply |
SOAPRequest (saída) |
Menagem de saída SOAP seguida por uma mensagem de entrada SOAP |
Nó SOAPRequest
|
Provedor externo recebendo a mensagem SOAP |
SOAPRequest (entrada) |
Menagem de saída SOAP seguida por uma mensagem de entrada SOAP |
Nó SOAPRequest |
Provedor externo recebendo a mensagem SOAP |
SOAPAsyncRequest |
Saída da mensagem SOAP |
Nó SOAPAsyncRequest |
Provedor externo recebendo a mensagem SOAP |
SOAPAsyncResponse |
Entrada da mensagem SOAP |
Nó SOAPAsyncRequest |
Provedor externo recebendo a mensagem SOAP |
Nós SOAPInput e SOAPReply
Neste diagrama, o intermediário age como destinatário. Um nó
SOAPInput recebe uma mensagem de um cliente (inicializador). Um nó
SOAPReply responde. Mensagens de entrada e saída são assinadas e criptografadas.
No pedido:- O inicializador utiliza o token de criptografia pública do intermediário para criptografar a mensagem e seu próprio token de assinatura privada para assiná-la.
- O intermediário utiliza seu próprio token de criptografia privada para decriptografar a mensagem e o token de assinatura pública do inicializador para verificar a assinatura.
Na resposta: - O intermediário utiliza o token de criptografia pública do inicializador para criptografar a mensagem e seu próprio token de assinatura privada para assinar a mensagem.
- O inicializador utiliza seu próprio token de criptografia privada para decriptografar a mensagem e o token de assinatura pública do intermediário para verificar a assinatura.
Nó SOAPRequest
Esse diagrama mostra o intermediário atuando como um inicializador. Utiliza o nó
SOAPRequest para fazer um pedido a um provedor externo (o destinatário). Mensagens de entrada e saída são assinadas e criptografadas. A utilização dos tokens é semelhante ao exemplo dos nós SOAP assíncronos, mostrados anteriormente.
No pedido:- O intermediário utiliza o token de criptografia pública do destinatário para criptografar a mensagem e seu próprio token de assinatura privada para assinar a mensagem.
- O destinatário utiliza seu próprio token de criptografia privada para decriptografar a mensagem e o token de assinatura pública do intermediário para verificar a assinatura.
Na resposta: - O destinatário utiliza o token de criptografia pública do intermediário para criptografar a mensagem e seu próprio token de assinatura privada para assinar a mensagem.
- O intermediário utiliza seu próprio token de criptografia privada para decriptografar a mensagem e o token de assinatura pública do inicializador para verificar a assinatura.
Nós SOAP Assíncronos
Esse diagrama mostra o intermediário atuando como um inicializador. Utiliza os nós SOAP assíncronos para fazer um pedido a um provedor externo (o destinatário). Mensagens de entrada e saída são assinadas e criptografadas.
No pedido:- O intermediário utiliza o token de criptografia pública do destinatário para criptografar a mensagem e seu próprio token de assinatura privada para assinar a mensagem.
- O destinatário utiliza seu próprio token de criptografia privada para decriptografar a mensagem e o token de assinatura pública do intermediário para verificar a assinatura.
Na resposta: - O destinatário utiliza o token de criptografia pública do intermediário para criptografar a mensagem e seu próprio token de assinatura privada para assinar a mensagem.
- O intermediário utiliza seu próprio token de criptografia privada para decriptografar a mensagem e o token de assinatura pública do inicializador para verificar a assinatura.