Fluxo para Estabelecer um Token de Contexto de Segurança para Conversas Seguras

Este cenário de exemplo descreve o fluxo de como o inicializador estabelece o token de contexto de segurança (SCT) usando o protocolo WS-Trust para segurança baseada na sessão com o destinatário. Depois de estabelecer o token de contexto de segurança, as chaves derivadas do token de contexto de segurança são utilizadas para assinar e criptografar a mensagem SOAP para fornecer proteção no nível da mensagem. Este exemplo tem como foco as trocas de mensagens utilizando o token de contexto de segurança no fluxo geral das mensagens SOAP.

A especificação WS-SecureConversation (Web Services Secure Conversation) do OASIS (Organization for the Advancement of Structured Information Standards) descreve maneiras de estabelecer uma sessão segura entre o inicializador e o destinatário de mensagens SOAP. A especificação WS-SecureConversation também define como usar o protocolo WS-Trust (Web Services Trust) para estabelecer um token de contexto de segurança. O produto suporta a Versão 1.3 e a versão de rascunho da especificação WS-SecureConversation.

O WebSphere Application Server suporta a capacidade de um terminal emitir um token de contexto de segurança para o WS-SecureConversation e fornece uma sessão segura entre o inicializador e o destinatário das mensagens SOAP.

A figura a seguir descreve o fluxo necessário para estabelecer um contexto seguro e usar a segurança baseada em sessão.

Figura 1. Exibindo o Fluxo entre o Cliente e o Serviço da Web e o Serviço de Token de SegurançaMostra o fluxo entre o cliente, o serviço de token de segurança e o serviço da Web

Trocando Mensagens entre o Inicializador e o Destinatário

A figura a seguir mostra como as mensagens são trocadas entre o inicializador e o destinatário para estabelecer o token de contexto de segurança. Os dois protocolos WS-Trust, RST (RequestSecurityToken) e RSTR (RequestSecurityTokenResponse), são utilizados para solicitar o token de contexto de segurança do terminal do destinatário.

A política de auto-inicialização é utilizada para proteger o RST e validar o pedido RSTR, que é geralmente diferente da política de segurança do aplicativo.

Figura 2. Utilizando Protocolos WS-Trust RST e RSTR para Estabelecer o SCT entre o Inicializador e o DestinatárioUtilizando o WS-Trust RST e RSTR para estabelecer o token de contexto de segurança entre o inicializador e o destinatário

Cenário que Descreve como Utilizar a Conexão Segura

Geralmente, para usar a conversação segura, as seguintes etapas estão envolvidas;
  1. O cliente envia um pedido de confiança RST (RequestSecurityToken) de um token de contexto de segurança para um terminal de aplicativo com sua chave secreta (entropia e tamanho da chave de destino) e solicita a chave secreta do serviço de destino.

    Essa solicitação normalmente é protegida com o Web Service Security assimétrico que é definido na política de autoinicialização.

  2. O RST é processado pelo serviço de confiança, se o pedido for confiável com base na política de segurança, o serviço de confiança retornará o token de contexto de segurança com a chave secreta do serviço de destino, utilizando um RSTR (WS-Trust RequestSecurityTokenResponse).

    Essa solicitação normalmente é protegida com o Web Service Security assimétrico. O cliente verifica se o RSTR pode ser confiável, com base na política de auto-inicialização.

  3. Se o RequestSecurityTokenResponse for confiável, o cliente protegerá (assinará e criptografará) as mensagens subsequentes do aplicativo, utilizando as chaves de sessão.

    As chaves de sessão são derivadas do segredo do token de contexto de segurança obtido das mensagens WS-Trust RequestSecurityToken e RequestSecurityTokenResponse iniciais que são trocadas entre o inicializador e o destinatário.

  4. A especificação define um algoritmo de como derivar a chave com base no segredo inicial. O serviço da Web de destino calcula a chave derivada a partir dos metadados contidos no cabeçalho de segurança da mensagem SOAP e o segredo inicial.
  5. O serviço da Web de destino usa a chave derivada para verificar e decriptografar a mensagem com base na política de segurança do aplicativo.
  6. O serviço da Web de destino usa a chave derivada a partir do segredo para assinar e criptografar a resposta com base na política de segurança do aplicativo.
  7. Repita as etapas de 3 a 6 até que a troca de mensagens tenha sido concluída.

Utilizando Chaves Derivadas do Segredo do Token de Contexto de Segurança

Depois que o token de contexto de segurança é estabelecido, as mensagens do aplicativo são protegidas com a proteção de mensagens, utilizando chaves derivadas do segredo do token de contexto de segurança. As chaves derivadas são utilizadas para proteger as mensagens do aplicativo, assinando e criptografando as mensagens do aplicativo. O token de contexto de segurança contém um UUID, que é utilizado como identificação de um segredo compartilhado. O UUID de token pode ser utilizado na mensagem SOAP para identificar o token de contexto de segurança para as trocas de mensagens. O segredo deve ser mantido na memória pelos participantes da sessão (neste caso, o inicializador e o destinatário) e protegido. O comprometimento do segredo debilita a conversação segura entre os participantes.

Figura 3. Protegendo Mensagens do Aplicativo com Chaves Derivadas do Segredo do Token de Contexto de SegurançaAs mensagens do aplicativo são protegidas com chaves derivadas do segredo do token de contexto de segurança

Um cenário semelhante, exceto com o WS-ReliableMessaging (Web Services Reliable Messaging), é possível a partir da perspectiva do WS-SecureConversation. Consulte o exemplo para estabelecer um token de contexto de segurança para proteger o sistema de mensagens confiável.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_establishsct_sc
Nome do arquivo: cwbs_establishsct_sc.html