Por que o WSE?

  • Artigo

Benjamin Mitchell

Fevereiro de 2005

Aplica-se a:

  • Microsoft .NET

  • WSE (Web Services Enhancements) 2.0 para Microsoft .NET

  • Especificações WS-*

Resumo: o WSE oferece benefícios, como a segurança de ponta a ponta no nível da mensagem, o roteamento com base no conteúdo e as diretivas, tirando proveito das especificações WS-Security, WS-Addressing e WS-Policy. Este artigo também contém links para páginas em inglês (7 páginas impressas).

Nesta página

O WSE é uma implementação de várias especificações WS-*
A segurança dos serviços da Web e o WS-Addressing oferecem segurança de ponta a ponta no nível da mensagem
Como funciona o WS-Security?
Aplicativo de exemplo: Um serviço de pagamento por cartão de crédito
Autenticação e assinatura com tokens de nome de usuário
Criptografando o corpo da mensagem com um certificado X.509
Roteamento com base no conteúdo com cabeçalhos derivados do WS-Addressing
Usando o WS-Policy para implementar a segurança com um mínimo de código
Resumo
Para obter mais informações

O Microsoft .NET sempre ofereceu um suporte robusto aos serviços da Web. Agora, com o lançamento do WSE (Web Services Enhancements) 2.0, é possível desenvolver serviços da Web seguros e interoperáveis com base nas especificações da indústria de código-fonte aberto. Este artigo destaca os benefícios oferecidos pelo WSE, como a segurança de ponta a ponta no nível da mensagem, o roteamento com base no conteúdo e as diretivas, tirando proveito das especificações WS-Security, WS-Addressing e WS-Policy.

O WSE é uma implementação de várias especificações WS-*

Grande parte da promessa dos serviços da Web é permitir a comunicação entre sistemas com diferentes sistemas operacionais e plataformas de desenvolvimento. Para tornar isso possível, os serviços são baseados em uma família de especificações de protocolos da indústria para os serviços da Web, geralmente denominada WS-*. O WSE 2.0 fornece implementações de várias dessas especificações para os usuários que desejam começar a usar hoje a tecnologia de serviços da Web de próxima geração. O WSE é um produto de download gratuito e com suporte completo que estende o suporte existente aos serviços da Web no .NET Framework. Embora não haja garantias de que o 2.0 será compatível com o tipo de conexão ou o modelo de objeto das versões principais futuras do WSE (por exemplo, a versão 3.0), a compatibilidade lado a lado com as versões principais é certa. Atualizações simples e mecânicas são esperadas para cada versão e para o "Indigo" — a infra-estrutura de mensagens da próxima geração para a plataforma Microsoft Windows. Espera-se que uma versão do WSE lançada antes do Indigo, ou simultaneamente a ele, seja interoperável com o Indigo no nível da conexão.

A segurança dos serviços da Web e o WS-Addressing oferecem segurança de ponta a ponta no nível da mensagem

A especificação WS-Security, agora aprovada como um padrão pelo OASIS [1], descreve como proteger os serviços da Web no nível da mensagem, e não no nível do protocolo de transporte ou da conexão. As soluções existentes no nível do transporte, como o SSL/TLS, fornecem criptografia e autenticação sólidas de ponto a ponto, mas possuem limitações caso uma mensagem precise ser processada ou examinada por um serviço intermediário. Por exemplo, várias organizações implantam um firewall de filtragem de camadas de aplicativos para examinar o tráfego antes que ele seja passado para uma rede interna.

Se uma mensagem precisar passar por vários pontos até chegar ao seu destino, cada ponto intermediário deverá encaminhar a mensagem por uma nova conexão SSL (veja a Figura 1). Nesse modelo, a mensagem original do cliente não é protegida por criptografia à medida que atravessa servidores intermediários, e dispendiosas operações adicionais de criptografia são executadas para cada nova conexão SSL estabelecida.

ms996935.whywse_01(pt-br,MSDN.10).gif
Figura 1. Segurança no nível do protocolo versus segurança no nível da mensagem

O WS-Addressing, recentemente submetido ao W3C [2], é um componente-chave para a obtenção da segurança no nível da mensagem, pois fornece os mecanismos necessários para lidar com as mensagens de uma forma independente do transporte. Isso permite que uma mensagem segura seja enviada através de qualquer transporte e seja facilmente roteada.

Há várias vantagens em proteger a mensagem em vez de usar o protocolo de transporte. Em primeiro lugar, esse método é mais flexível, pois partes da mensagem, e não a mensagem inteira, podem ser assinadas ou criptografadas. Isso significa que os intermediários conseguirão ver as partes da mensagem destinadas a eles. Um exemplo é um serviço da Web que roteia mensagens SOAP e é capaz de inspecionar partes não criptografadas de uma mensagem para determinar o local para onde a mensagem deverá ser enviada, enquanto outras partes da mensagem permanecem criptografadas. Depois, os intermediários poderão adicionar seus próprios cabeçalhos à mensagem e assiná-la para fins de registro de auditoria. Finalmente, a mensagem protegida poderá ser enviada através de vários protocolos diferentes, como SMTP, FTP e TCP, sem que seja preciso contar com o protocolo para garantir a segurança.

Como funciona o WS-Security?

O WS-Security define como garantir a integridade, a confidencialidade e a autenticação das mensagens com o sistema de transmissão de mensagens SOAP. A autenticação está relacionada à identificação do chamador. O WS-Security usa tokens de segurança para manter essas informações com um cabeçalho de segurança da mensagem SOAP. A integridade da mensagem é obtida com Assinaturas digitais XML. Isso garante que partes da mensagem não tenham sido adulteradas após a assinatura do originador. A confidencialidade da mensagem é baseada na especificação de criptografia XML e garante que partes correspondentes da mensagem só possam ser compreendidas pelo(s) destinatário(s) desejado(s).

ms996935.whywse_02(pt-br,MSDN.10).gif
Figura 2. Serviço da Web de processamento de cartão de crédito Fabrikam

Aplicativo de exemplo: Um serviço de pagamento por cartão de crédito

Para demonstrar os benefícios do uso do WSE, imagine o serviço da Web fictício de processamento de cartão de crédito Fabrikam (veja a Figura 2), que permite que aplicativos cliente submetam detalhes de cartão de crédito para pagar por uma compra. Os clientes da Fabrikam precisam pagar uma assinatura mensal para acessar esse serviço. Eles também recebem uma fatura mensal referente ao número de transações processadas. O custo por transação depende da velocidade de processamento, que pode tanto ser imediata quanto durante a noite.

Para que haja suporte a esse cenário, cada chamada ao serviço da Web deve conter informações de autenticação, para que os serviços internos possam verificar se o cliente ainda possui uma assinatura mensal. Os detalhes do cartão de crédito devem ser mantidos em segurança até que a mensagem seja recebida por algum dos serviços internos de pagamento. As seções a seguir descrevem como o WSE dá suporte a esses requisitos.

Autenticação e assinatura com tokens de nome de usuário

Os clientes são autenticados com um token de nome de usuário que contém um nome de usuário e uma senha. O serviço de pagamento usa o WSE para implementar um UsernameTokenManager personalizado que valida o nome do usuário e a senha em relação ao armazenamento cliente de detalhes do usuário (veja a Listagem 1). Os clientes também assinam a mensagem usando esse token de nome de usuário, e o serviço de pagamento usa o WSE para validar automaticamente a assinatura, garantindo que a mensagem não tenha sido adulterada. O UsernameTokenManager é apenas um exemplo de como o WSE pode ser estendido além do seu comportamento padrão, que é validar o nome de usuário/a senha em relação a um domínio do Windows ou a uma conta de usuário local. Observe que as práticas recomendadas não estão no escopo deste documento. O Kerberos, o X509 ou ainda os tipos de token XML ou binários personalizados podem ser preferíveis em determinados cenários. Consulte o centro do desenvolvedor de serviços da Web no MSDN para obter artigos mais completos sobre segurança [3].

Listagem 1. Criando um gerenciador de token de nome de usuário personalizado

public class CustomUsernameTokenManager : UsernameTokenManager
{
   protected override string AuthenticateToken(UsernameToken token)
   {
      // Call our application's business logic to get the password
      string storedApplicationHashedPassword = 
       GetAppPasswordHashFromUserDetailsStore( token.Username );
   if ( storedApplicationHashedPassword != null )
   {
     return storedApplicationHashedPassword;
   }
   else
   {
      throw new SecurityFault( "An invalid security token was
            provided", SecurityFault.InvalidSecurityTokenCode );
   }
   }
}

Criptografando o corpo da mensagem com um certificado X.509

Os aplicativos cliente usam o certificado X.509 do departamento de contas da Fabrikam (que é instalado na máquina de cada cliente) para criptografar as informações de cartão de crédito (veja a Listagem 2). Como o roteador HTTP do WSE não processa nenhuma informação de segurança na mensagem, ele não conseguirá ver os detalhes do cartão de crédito contidos no corpo criptografado do envelope SOAP. Os detalhes de cartão de crédito são protegidos uma vez no cliente e só são descriptografados quando a mensagem é recebida pelos Serviços de processamento imediato ou durante a noite.

Listagem 2. Criptografando o corpo da mensagem usando um certificado X509

// Encrypt the message body with the credit card details using the 
// Accounts Department Certificate
X509SecurityToken x509Cert =   
    GetFabrikamAccountsDepartmentCertificate();
paymentServiceProxy.RequestSoapContext.Security.Tokens.Add( x509Cert );
paymentServiceProxy.RequestSoapContext.Security.Elements.Add( new 
EncryptedData( x509Cert ) );

Roteamento com base no conteúdo com cabeçalhos derivados do WS-Addressing

Os clientes enviam as mensagens a um único serviço de roteamento publicamente visível. Esse serviço usa o suporte ao endereçamento e ao roteamento do WSE para inspecionar os cabeçalhos da mensagem a fim de determinar para qual serviço interno de pagamento a mensagem será enviada. Fazer com que um serviço da Web roteie as mensagens SOAP dessa forma é uma maneira de "virtualizar" a rede física, implementar o balanceamento de carga ou permitir que os serviços sejam movidos ou substituídos sem prejudicar os clientes.

O WSE dá suporte a roteadores HTTP que são hospedados no IIS (eles implementam IHttpHandler). A Listagem 3 mostra o PaymentServiceRouter, derivado do SoapHttpRouter do WSE, que faz a maior parte do seu trabalho dentro da função ProcessRequestMessage, onde ele pesquisa um cabeçalho de mensagem de processamento intermediário (adicionado por meio do suporte do WS-Addressing a propriedades de referência que são transformadas em cabeçalhos SOAP autônomos) para determinar onde a mensagem será roteada. A Listagem 4 mostra o referralCache.xml usado para configurar o roteador.

Listagem 3. Implementando o roteador do servidor de pagamento

public class PaymentServiceRouter : 
Microsoft.Web.Services2.Messaging.SoapHttpRouter
{
   static readonly string ImmediateProcessingURI = 
"http://fabrikam/ImmediatePaymentService.asmx";
   static readonly string ImmediateProcessingName = "Immediate";

   Uri AccountsPaymentServiceURI;

   public PaymentServiceRouter()
   {
      AccountsPaymentServiceURI = new Uri(ImmediateProcessingURI);
   }

   protected override Uri ProcessRequestMessage(SoapEnvelope message)
   {
      // Look for any Immediate headers
      XmlNodeList immediateHeaders = 
         message.Header.GetElementsByTagName(
         ImmediateProcessingName, ImmediateProcessingURI);
        if (immediateHeaders.Count == 0)
        {
            // Defer to the WSE RoutingHandler's implementation
      // to send it to the Overnight Batch Service specified
      // in the config.
            return base.ProcessRequestMessage(message);
        }
        else
        {
            // Add a new via to the accounts payment service
            return AccountsPaymentServiceURI;
        }
    }
}

Listagem 4. O cache de referência do roteador do servidor de pagamento

<?xml version="1.0" ?>
<r:referrals xmlns:r="https://schemas.xmlsoap.org/ws/2001/10/referral">
  <r:ref>
    <r:for>
      <r:exact>https://fabrikam.com/PaymentService.asmx</r:exact>
    </r:for>
    <r:if />
    <r:go>
      <r:via>http://fabrikam/OvernightPaymentService.asmx</r:via>
    </r:go>
    <r:refId>uuid:fa469956-0057-4e77-962a-81c5e292f2ae</r:refId>
  </r:ref>
</r:referrals>

Usando o WS-Policy para implementar a segurança com um mínimo de código

Embora o WSE forneça suporte automático para a verificação de assinaturas e a descriptografia de elementos criptografados, ainda é trabalho dos implementadores de serviços escrever códigos para verificar se as partes corretas das mensagens recebidas foram assinadas e criptografadas com os tokens adequados. Como uma alternativa a escrever esse código dentro dos serviços, o WSE dá suporte ao WS-Policy, que define uma sintaxe XML que pode ser usada para descrever os requisitos além da capacidade do WSDL. O WSE do serviço usa esse arquivo XML para validar automaticamente as mensagens SOAP recebidas. De forma semelhante, o cliente pode usar um arquivo de diretivas correspondente para proteger automaticamente a comunicação enviada. Como resultado, os desenvolvedores precisarão escrever menos códigos, e será possível alterar os requisitos de segurança sem que seja necessário recompilar o código do serviço. O WSE também fornece um Security Settings Wizard (Assistente de Configurações de Segurança) que pode ser usado para criar o arquivo de diretivas XML.

Resumo

O WSE, como um complemento do .NET Framework, fornece um kit de ferramentas que pode ser usado pelos desenvolvedores para proteger serviços da Web interoperáveis baseados em várias especificações WS-*, como WS-Security, WS-Addressing e WS-Policy. O aplicativo de exemplo demonstra os benefícios de se usar o WSE 2.0 para obter a segurança de ponta a ponta no nível da mensagem, o roteamento com base no conteúdo e as diretivas para a criação de aplicativos que seriam difíceis de desenvolver com as tecnologias distribuídas anteriormente.

Para obter mais informações

  1. Site do OASIS Web Services Security (WSS) TC (em inglês)

  2. WS-Addressing Specification Draft no site do W3C (em inglês)

  3. Página do Web Services Enhancements no MSDN Web Services Developer Center (em inglês)

© .