![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
O tópico deste artigo é fornecido em duas partes. A primeira parte aborda recursos de WS-Security, o relacionamento entre participantes de negócios e os mecanismos de como os recursos de WS-Security são implementados. A segunda parte descreverá o suporte do IBM® WebSphere® Application Server a WS-Security, necessidades de negócios dos clientes e como utilizaram WS-Security e outras tecnologias de segurança em suas soluções operacionais.
Implicações do uso de segurança
Opções de design e implementações que abordam requisitos de segurança frequentemente têm um impacto adverso no desempenho de uma solução. Isso não é sugerir que todas as tecnologias de segurança usadas em soluções resultem em desempenho lento. Na verdade, você deveria estar ciente de que soluções de serviços da Web que requerem autenticação de participantes de negócios, assinatura digital de conteúdo da mensagem e criptografia de dados XML podem ter características de desempenho muito diferentes com base na tecnologia ou método usados para proteger as funções e dados de negócios expostos de uma solução.
A tríade de segurança abordada neste artigo engloba: (a) autenticação, (b) integridade de dados e (c) confidencialidade de dados. Se não for um especialista nos mecanismos para abordar esses requisitos de segurança, eu forneço uma visão geral resumida abaixo antes de entrar de cabeça nos detalhes de como é possível implementá-los.
Autenticação é usada para assegurar que partes de uma transação de negócios são realmente quem dizem ser; assim, uma prova de identidade é necessária. Essa prova pode ser fornecida de várias maneiras. Um exemplo simples é apresentar um ID de usuário juntamente com uma senha secreta. Um exemplo mais complexo é um que use um certificado X.509 emitido por uma Autoridade de Certificação confiável (como a Verisign). O certificado contém credenciais de identidade e tem um par e chaves privada e pública associadas a ele. A prova de identidade apresentada por uma parte inclui o próprio certificado e um conjunto de informações separado assinado digitalmente usando a chave privada do certificado. Ao validar as informações assinadas usando a chave pública associada ao certificado da parte, o destinatário pode autenticar o remetente como sendo o proprietário do certificado, validando assim sua identidade. Quando ambas as partes autenticam uma a outra, isso é chamado de autenticação mútua e é feito frequentemente entre um consumidor do serviço da Web e um provedor de serviços da Web.
Para validar a integridade de informações de negócios trocadas em uma transação assegurando que o conteúdo da mensagem não tenha sido alterado nem danificado durante sua transmissão pela Internet, os dados podem ser assinados digitalmente usando chaves de segurança. Esse é o segundo requisito da tríade de segurança. Uma prática comum é usar a chave privada do certificado X.509 do remetente para assinar digitalmente o corpo SOAP de uma solicitação de serviço da Web. De forma semelhante, blocos de cabeçalho SOAP em uma solicitação também podem ser assinados para assegurar a integridade das informações trocadas em uma transação que está fora do escopo do contexto de negócios real (por exemplo, IDs de mensagens, tokens de segurança). Da mesma forma, uma resposta de serviços da Web pode ser assinada digitalmente para assegurar a integridade de dados.
O terceiro requisito da tríade de segurança é confidencialidade. Tecnologia de criptografia pode ser usada para tornar as informações trocadas em solicitações e respostas de serviços da Web ilegíveis. O propósito é assegurar que qualquer pessoa que esteja acessando os dados em trânsito, na memória ou após terem sido persistidos precisaria dos algoritmos apropriados e das chaves de segurança para decriptografar os dados antes de poder acessar as informações em si.
Hoje em dia, é possível implementar todas as medidas de segurança usando vários mecanismos. Com base em seus requisitos específicos e ambiente de negócios, será possível fazer uma opção entre aqueles que dependem do transporte ou aqueles específicos do sistema de mensagens SOAP.
Como este artigo faz parte da série Melhores Práticas para Serviços da Web , focará principalmente as várias maneiras de aproveitar WS-Security em suas soluções e o impacto no desempenho que deve ser esperado.
A especificação WS-Security está em seu processo de aprovação final no órgão de normas OASIS e fornece mecanismos para abordar todos os três requisitos descritos como a tríade de segurança entre terminais de aplicativos. Com WS-Security, é possível implementar de forma seletiva cada um dos requisitos da tríade de segurança, de forma que um ou todos eles sejam abordados em sua solução.
Um aplicativo que requer os serviços de outro aplicativo é considerado o Aplicativo Consumidor para este artigo. Faço referência ao aplicativo que fornece os serviços como o Provedor de Serviços. O diagrama abaixo ilustra esse relacionamento e é a base para grande parte da discussão a seguir:
Figura 1 - Ambiente do sistema
Para o cenário descrito e ilustrado nas seções a seguir, a chave pública do certificado X.509 do Provedor de Serviços deve ser trocada com o cliente e configurada no tempo de execução do cliente antes de chamar os serviços do Provedor de Serviços. Para o Aplicativo Consumidor e para o Provedor de Serviços, o certificado raiz da Autoridade de Certificação (como a Verisign) que emitiu os certificados das partes precisará ser importado para os keystores locais. O keystore do Aplicativo Consumidor terá o certificado raiz do certificado do Provedor de Serviços. Da mesma forma, o keystore do Provedor de Serviços irá requerer o certificado raiz do certificado do Aplicativo Consumidor. Isso é obrigatório e permite validação das assinaturas digitais dos certificados individuais que são passados como tokens de segurança nas mensagens SOAP.
Uma implementação integral de todos os requisitos de segurança incluiria:
- Os remetentes da solicitação ou resposta de serviços da Web
- Assinatura da mensagem com chave privada de seu certificado X.509
- Criptografia da mensagem com a chave pública do certificado X.509 do destinatário para assegurar que somente ele possa acessar o conteúdo da mensagem
- Os destinatários da solicitação ou resposta de serviços da Web
- Verificação da assinatura da mensagem usando a chave pública do remetente para autenticar o remetente e para verificar a integridade da mensagem
- Decriptografar a mensagem com a chave privada de seu certificado X.509
Detalhes de criptografia XML de WS-Security
A criptografia de dados baseada na especificação WS-Security e as especificações de Criptografia XML às quais faz referência envolve:
- Um processo em duas fases usando algoritmos simétricos e assimétricos.
- Uma chave compartilhada é usada para criptografar/decriptografar os dados da mensagem usando um algoritmo simétrico, como Triple DES. Algoritmos simétricos são muito eficientes e funcionam com uma única chave para cálculos de criptografia e decriptografia. Implementações de WS-Security usam uma chave que é raramente gerada. Quando os dados da mensagem forem criptografados, a própria chave é inserida na mensagem. (Observe que a chave também é criptografada conforme descrito abaixo.)
- Passar a chave compartilhada na mensagem SOAP com a chave criptografada/decriptografada usando um algoritmo assimétrico, como RSA-V1.5. A criptografia da chave compartilhada é executada de forma diferente dos dados da mensagem com um algoritmo que utiliza um par de chaves -- privada e pública. Um certificado X.509 tem duas chaves, uma que é privada do proprietário do certificado e uma segunda chave que é compartilhada com outros com os quais está realizando negócios. Algoritmos simétricos são mais eficientes do que algoritmos assimétricos; no entanto, eles requerem gerenciamento de chaves compartilhadas entre as partes e têm riscos de segurança inerentes de serem expostos a outros fora de sua organização ou parceiros de negócios. Assim, usando somente algoritmos assimétricos na chave aleatória, WS-Security fornece uma solução relativamente eficiente e uma que é fácil de gerenciar. Na Parte Dois deste artigo, discutirei porque uso a palavra relativamente.
Consulte os links da seção Recursos para obter detalhes de Criptografia XML.
Cenário de WS-Security do mundo real
O cenário descrito abaixo é uma de muitas possibilidades que podem ser realizadas com WS-Security. Usa certificados X.509, uma prática comum em diversas das soluções de clientes que descreverei na Parte Dois deste artigo.
Processamento do Aplicativo Consumidor de solicitação de serviços da Web
Geralmente, o Aplicativo Consumidor terá um Proxy de Serviço ou um componente stub JAX-RPC que tenha sido gerado a partir de um Ambiente de Desenvolvimento Integrado (como o WebSphere Studio Application Developer) usando WSDL do Provedor de Serviços. Quando uma chamada de serviços da Web é feita, o tempo de execução proxy ou SOAP no sistema do cliente executa as funções de WS-Security antes de enviar a solicitação.
Primeiro, a mensagem SOAP é assinada digitalmente. O tempo de execução SOAP pode acessar um keystore para recuperar chaves de segurança e certificados, conforme necessário. Dependendo do suporte a WS-Security que seu ambiente fornece, pode ser possível assinar somente o corpo SOAP ou pode ser possível assinar elementos individuais dentro do corpo. Além disso, blocos de cabeçalho SOAP podem ser assinados. A assinatura é executada usando a chave privada do certificado X.509 do Aplicativo Consumidor. Quando a mensagem tiver sido assinada, o próprio certificado X.509 é incluído no cabeçalho SOAP como o token de segurança binário. A mensagem é criptografada usando um algoritmo simétrico com uma chave compartilhada. A chave usada para a criptografia de dados é ela mesma criptografada usando um algoritmo assimétrico com a chave pública associada ao certificado X.509 do Provedor de Serviços. Quando a mensagem e a chave compartilhada tiverem sido criptografadas, uma referência ao certificado X.509 do Provedor de Serviços para quem a solicitação está sendo enviada é incluída no cabeçalho SOAP. Isso é feito porque o Provedor de Serviços pode estar usando diversos certificados.
Figura 2 - Processamento do Aplicativo Consumidor de solicitação com WS-Security
Processamento do Provedor de Serviços de solicitação de serviços da Web
Quando um Provedor de Serviços recebe uma solicitação de serviços da Web, a solicitação é direcionada ao mecanismo de processamento SOAP (tempo de execução SOAP) com base na URL da solicitação (ponto de acesso publicado para o serviço). Os dados da mensagem e a chave compartilhada passados na solicitação são criptografados, portanto, a primeira etapa é identificar o certificado X.509 referido no cabeçalho SOAP e recuperar sua chave privada de um keystore. Quando a chave privada for obtida, a chave compartilhada pode ser decriptografada usando um algoritmo assimétrico. Com a chave compartilhada abertamente, os dados da mensagem podem ser decriptografados usando um algoritmo simétrico. Com toda a mensagem agora no aberto, o certificado X.509 passado no cabeçalho SOAP pode ser acessado para recuperar sua chave pública. A assinatura digital da mensagem é executada com a chave pública do Aplicativo Consumidor. Como resultado da validação bem-sucedida da assinatura, o tempo de execução SOAP do Provedor de Serviços não apenas valida a integridade da mensagem, mas também é assegurado de que o Aplicativo Consumidor realmente assinou a mensagem. Esse processo também autentica a origem/remetente da mensagem, pois somente o remetente que possui o certificado tem acesso à chave privada usada para assinar a mensagem. Quando a mensagem tiver sido decriptografada e a assinatura validar, o tempo de execução SOAP chama a implementação de serviços da Web.
Figura 3 - Processamento do Provedor de Serviços de solicitação com WS-Security
Processamento do Provedor de Serviços de resposta de serviços da Web
Quando a lógica de negócios da implementação de serviço tiver sido executada e uma resposta estiver disponível, as mesmas operações de WS-Security ocorrem para a mensagem de resposta de serviços da Web. No entanto, as funções dos pares de chaves X.509 são revertidas para assinatura digital e criptografia. O tempo de execução SOAP do Provedor de Serviços assina digitalmente a mensagem usando a chave privada de seu próprio certificado X.509. O certificado é incluído na mensagem SOAP e a mensagem é criptografada usando uma chave compartilhada. A chave usada para a criptografia de dados poderia ser a mesma chave passada na solicitação original ou outra chave gerada aleatoriamente, a segunda opção sendo mais comum. A criptografia da chave compartilhada é executada usando a chave pública do certificado que foi passado na solicitação; assim somente o remetente da solicitação que tem acesso à chave privada do certificado é a única parte que pode decriptografar a mensagem. Após a mensagem ser assinada e criptografada, o tempo de execução SOAP do Provedor de Serviços envia a resposta ao Aplicativo Consumidor.
Figura 4 - Processamento do Provedor de Serviços de resposta com WS-Security
Processamento do Aplicativo Consumidor de resposta de serviços da Web
O processamento de WS-Security da resposta de serviços da Web do Aplicativo Consumidor é muito semelhante a o que o Provedor de Serviços executou para a solicitação.
O Aplicativo Consumidor recebe uma resposta de serviços da Web com a resposta direcionada ao mecanismo de processamento SOAP (tempo de execução SOAP) com base na sessão HTTP original. Os dados da mensagem e a chave compartilhada passados na resposta são criptografados. Portanto, a etapa inicial é recuperar a chave privada do certificado associado à solicitação correspondente para decriptografar a chave compartilhada usando um algoritmo assimétrico. Com a chave compartilhada abertamente, os dados da mensagem podem ser decriptografados usando um algoritmo simétrico. Após toda a mensagem estar no aberto, o certificado X.509 passado no cabeçalho SOAP pode ser acessado para recuperar sua chave pública. A assinatura digital da mensagem de resposta é executada com a chave pública do Provedor de Serviços. Após a validação bem-sucedida da assinatura, o tempo de execução SOAP do Aplicativo Consumidor não apenas valida a integridade da mensagem, mas também é assegurado de que o Provedor de Serviços realmente assinou a mensagem. Esse processo também autentica a origem/remetente da mensagem, pois somente o remetente que possui o certificado tem acesso à chave privada usada para assinar a mensagem. Após a mensagem ser decriptografada e assinatura validada, o tempo de execução SOAP encaminha a resposta ao Aplicativo Consumidor.
Figura 5 - Processamento do Aplicativo Consumidor de resposta com WS-Security
No fundo, WS-Security é muito complexo e pode ser utilizado em muitos cenários diferentes. O exemplo descrito acima tem muitos aspectos que clientes têm implementado hoje em dia. Parte ou todo o cenário foi implementado por clientes nas plataformas WebSphere Application Server, dependendo de suas políticas de segurança existentes, da infraestrutura de segurança ou das necessidades de negócios. Isso será discutido na Parte Dois deste artigo.
A boa notícia é que o suporte do WebSphere Application Server para WS-Security é por meio de um modelo declarativo. Assim, quando tiver implementações de serviços da Web desenvolvidas e testadas, a ativação de recursos de WS-Security é realizada facilmente durante a fase de implementação. Como resultado, a complexidade da Assinatura Digital XML e da Criptografia XML devem ser de pouca preocupação para você como um IT Architect ou IT Specialist.
- Participar do fórum de discussão.
- Consulte toda a série da coluna Melhores Práticas.
- Exercício de laboratório para o WebSphere Studio Application Developer: Secure Web Services with WS-Security.
- Faça este tutorial sobre interoperabilidade de serviços da Web seguros (developerWorks, fevereiro de 2004).
- Rascunho inicial do grupo de trabalho de Web Services Interoperability (WS-I): Basic Security Profile Scenarios.
- Informações sobre Segurança de Serviços da Web: WS-Security.
- Sintaxe e Processamento de Criptografia XML: W3C Specification.
- Sintaxe e Processamento de Assinatura XML: W3C Specification.
- Localize informações adicionais sobre o suporte de segurança de Serviços da Web do WebSphere Application Server no Centro de Informações do WebSphere.
Holt Adams é Executive IT Architect no grupo Emerging Technology de software IBM, onde ele atualmente fornece suporte à Equipe jStart Program and Customer Innovation da IBM. Suas qualificações permitem que tenha as funções de arquiteto de soluções e gerente de identificação de novos negócios para ser um catalisador efetivo na adoção pelo cliente de tecnologias emergentes da Internet. Ele tem experiência como profissional tanto nos aspectos comerciais quanto técnicos de identificação de novos negócios de clientes de atividades que incluem geração de liderança, qualificação de negócios, gerenciamento de requisitos, arquitetura de solução, design de solução e negociações de contratos. Como um IT Architect, Holt refina as necessidades de negócios dos clientes para requisitos de TI que podem ser abordados com recursos de TI de tecnologias emergentes no desenvolvimento e soluções de ponta. Durante seu exercício no cargo no jStart Program e em outros trabalhos relacionados a serviços, seu portfólio de tecnologia incluiu computação wireless/disseminada, infraestrutura da Internet, Java/J2EE, XML, serviços da Web/SOA, software livre, Web 2.0, rede social e tecnologias mashup corporativas.
