CENTRO UNIVERSITÁRIO DE MARINGÁ

CURSO DE PÓS-GRADUAÇÃO EM DESENVOLVIMENTO ORIENTADO A

OBJETOS - JAVA

MICHAEL LUIZ PEREIRA

WEB SERVICES SEGUROS EM JAVA

MARINGÁ
2008
 MICHAEL LUIZ PEREIRA

WEB SERVICES SEGUROS EM JAVA

Monografia apresentada ao Centro

Universitário de Maringá como requisito para

obtenção do título de especialista em

Desenvolvimento Orientado a Objetos - Java,

sob orientação do professor CESAR

FERNANDO MORO

MARINGÁ
2008
 DETICATÓRIA

A Elaine Sueli Kind, minha companheira, que me

deu força e ânimo para a conclusão deste curso e

trabalho.
AGRADECIMENTOS

Aos meus amigos de classe pela alegria e

incentivo.

A Cesar Fernando Moro pela dedicação e

competência.

A minha mãe Dircelia, por ajudar a este sonho

realizar.

Enfim, sou muito grato a todos que contribuíram

direta ou indiretamente para a realização deste

curso. E peço perdão àqueles a quem não citei

nominalmente, mas que tenham a certeza de que

a tônica constante em todas as fases de realização

desta etapa foi a sua presença.

 EPÍGRAFE

A imaginação é mais importante que o conhecimento.

Albert Einstein
 RESUMO

No momento, a arquitetura orientada a serviços encontra-se no radar de muitos

gerentes de TI, e um numero maior de empresas passam a dedicar cada vez mais

recursos à SOA. Se a SOA é a arquitetura, os Web Services são os blocos de

construção (IBM, 2008). Desta forma, Web Services estão em destaque no mundo

da computação distribuída como uma tecnologia que resolve os problemas de

interoperabilidade dos sistemas, pois utilizam padrões abertos e independentes de

plataforma, como HTTP e XML. Porem, por possuir uma infra-estrutura publica

oferece, também, uma maior preocupação no tocante a segurança. Neste presente

trabalho pretende-se demonstrar o funcionamento de Web Services seguros

utilizando a tecnologia Java abordando conceitos da arquitetura orientada a

serviços. Através de um estudo de caso será implementado Web Services, com o

auxilio de frameworks como Apache Axis e CXF, utilizando os padrões de protocolos

adotados pela industria demonstrando a especificação WS-Security.

Palavras-chave: JAVA, Web Services, Segurança.

 ABSTRACT

Currently, the service-oriented architecture is in the radar of many IT managers, and

a higher number of companies now have to devote more resources to the SOA. If the

SOA is the architecture, Web Services are the building blocks of (IBM, 2008). Thus,

Web Services are highlighted in the world of distributed computing as a technology

that solves the problems of interoperability of systems, it uses open standards and

platform-independent, like HTTP and XML. However, for having an infrastructure

publishes offers, too, a greater concern with regard to security. In this study aims to

demonstrate the safe operation of Web Services using Java technology addressing

the concepts of service oriented architecture. Through a case study will be

implemented Web Services, with the aid of frameworks such as Apache Axis and

CXF, using industry standard protocols used by industry for demonstrating the WS-

Security specification.

Key words: JAVA, Web Services, Security.

 LISTA DE FIGURAS

Figura 1 - Mensagens trocadas na invocação de um Web Service. Fonte: ROSENBERG, 2004 ......... 9
Figura 2 - Esqueleto mensagem SOAP. Fonte: XYZWS, 2008............................................................ 12
Figura 3 - Exemplo WSDL. Fonte: XYZWS, 2008 ................................................................................ 15
Figura 4 - UDDI em uma arquitetura orientada a serviços. Fonte: ROSENBERG, 2004 ..................... 17
Figura 5 - Lista dos jars do projeto Terceiro ......................................................................................... 29
Figura 6 - Classe Servidor projeto Server............................................................................................. 30
Figura 7 - WSDL do serviço .................................................................................................................. 31
Figura 8 - Classe Cliente projeto Client com o retorno da execução.................................................... 32
Figura 9 - Plugin do Eclipse gerar stub Axis ......................................................................................... 33
Figura 10 - Classe Terceiro do projeto utilizando framework Axis........................................................ 33
Figura 11 - Classe ServerCallbackHandler projeto Server .................................................................. 36
Figura 12 - Classe UsernameTokenInterceptor .................................................................................... 37
Figura 13 - Alterações na classe Servidor ............................................................................................ 37
Figura 14 - Implementação CallbackHandler no projeto Client ............................................................ 38
Figura 15 - Alterações para autenticação na classe Cliente................................................................. 39
Figura 16 - Arquivo wsdd responsável pelas configurações no Axis.................................................... 39
Figura 17 - Alterações para autenticação na classe Terceiro............................................................... 40
Figura 18 - Soap request e resultado da chamada Web Service com autenticação............................ 41
Figura 19 - Processo de criptografia simétrico. Fonte: ROSENBERG, 2004 ....................................... 42
Figura 20 - Processo de criptografia assimétrico. Fonte: ROSENBERG, 2004 ................................... 43
Figura 21 - Gerar par de chaves pelo Keytool ...................................................................................... 44
Figura 22 - Arquivo wsdd alterado para criptografar a mensagem....................................................... 47
Figura 23 - Soap request e resultado da chamada Web Service com criptografia .............................. 47
Figura 24 - Processo de assinatura digital. Fonte: ROSENBERG, 2004 ............................................. 48
Figura 25 - Processo de verificação da assinatura digital. Fonte: ROSENBERG, 2004 ...................... 49
Figura 26 - Arquivo wsdd alterado para assinar digitalmente a mensagem......................................... 50
Figura 27 - Parte da mensagem SOAP utilizando o processo de assinatura digital ............................ 51
 SUMÁRIO

1. INTRODUÇÃO .................................................................................................................................... 1
1.1 Contexto do Trabalho.............................................................................................................. 1
1.2 Justificativa.............................................................................................................................. 2
1.3 Objetivo ................................................................................................................................... 3
1.4 Organização do trabalho......................................................................................................... 4
2. FUNDAMENTAÇÃO TEÓRICA........................................................................................................... 5
2.1 Arquitetura Orientada a Serviços (SOA)................................................................................. 5
2.2 Web Services .......................................................................................................................... 7
2.3 XML ......................................................................................................................................... 9
2.4 SOAP .................................................................................................................................... 10
2.5 WSDL .................................................................................................................................... 13
2.6 UDDI...................................................................................................................................... 16
2.7 Frameworks .......................................................................................................................... 17
2.7.1 Apache Axis ....................................................................................................................... 18
2.7.2 Apache CXF....................................................................................................................... 19
2.8 Segurança em Web Services ............................................................................................... 20
2.8.1 Análise das Ameaças Versus Mecanismos de Segurança ............................................... 21
2.9 WS-Security .......................................................................................................................... 22
2.9.1 XML Encryption.................................................................................................................. 23
2.9.2 XML Signature ................................................................................................................... 24
2.9.3 SAML ................................................................................................................................. 24
3. ESTUDO DE CASO .......................................................................................................................... 26
3.1 Visão Geral ........................................................................................................................... 26
3.2 Pré-requisitos ........................................................................................................................ 28
3.3 Implementando os Web Services ......................................................................................... 30
3.4 Autenticação ......................................................................................................................... 34
3.5 Criptografia............................................................................................................................ 41
3.6 Assinatura Digital .................................................................................................................. 48
4. CONCLUSÃO.................................................................................................................................... 52
REFERÊNCIAS BIBLIOGRÁFICAS...................................................................................................... 54
1. INTRODUÇÃO

Neste capítulo será apresentado o contexto em que o trabalho se enquadra, os fatos

que o justificam, seu objetivo e a organização do trabalho como um todo.

1.1 Contexto do Trabalho

A tecnologia da informação tem apresentado nos últimos anos fases bem

definidas e a fase atual é sem duvidas, marcada pelo surgimento e popularização da

Internet. Quando a Internet começou a se popularizar, por volta do meio dos anos

90, as tecnologias presentes permitiam conectar-se a um site e baixar o conteúdo

deste. O HTML (Hiper Text Markup Language) era a linguagem que permitia a

apresentação da informação presente na rede. Nos últimos anos, porém, novas

tecnologias e frameworks de desenvolvimento estão surgindo, permitindo uma maior

integração entre os diversos aplicativos e serviços disponíveis na Internet.

Baseado nesse contexto surge a tecnologia Web Services (W3C, 2008), que

tem por objetivo integrar sistemas distintos e prover serviços através da Internet

usando protocolos padronizados que garantem a independência de plataforma e de

linguagem de programação em que esses sistemas foram escritos. Assim é possível

disponibilizar uma coleção de métodos em um servidor remoto e permitir que sejam

acessados por programas clientes.

A segurança é atualmente considerada como um fator decisivo no sucesso

dos sistemas distribuídos. Os requisitos de segurança variam desde a privacidade,

confiabilidade até integridade de dados, para assegurar a realização de uma

transação virtualmente na Web.

1
 1.2 Justificativa

Com o advento da Internet o volume de informações compartilhadas

aumentou consideravelmente, e junto com isso, a cada dia surgem novas

tecnologias e dispositivos para atender a essa demanda com mais agilidade e

flexibilidade.

Sendo assim, Web Services apresentam-se como mecanismos eficientes

para disponibilizar novos serviços, compartilhando lógica e dados através de

múltiplas aplicações e modelos de uso. De acordo com recente análise da IDC (IDC,

2007) com o aumento do número de serviços disponibilizados por organizações,

cresce também a preocupação por parte das empresas com a segurança da

informação. Desta maneira, estes dados muitas vezes devem ser disponibilizados de

forma segura, para que as partes tenham garantia que tais informações somente

possam ser compartilhadas com autorização, confiabilidade, integridade e não

repúdio (ICP-BRASIL, 2008).

Alem disso, surge uma mudança de paradigma quanto a orientação de

serviços. As aplicações que até então trabalhavam de forma centralizada, passa a

trocar informações em um ambiente de sistemas distribuídos e fazem isso muitas

vezes utilizando-se da Internet. A web que sempre teve em sua ponta final o usuário,

passa a ter uma aplicação realizando o papel de cliente . Tornando-se não mais uma

grande rede e sim uma plataforma, não mais oferecendo somente informação mais

também serviços.

Essa exposição dos serviços na rede e a excessiva troca de mensagens

entre os componentes trazem uma maior preocupação quanto a aspectos de

segurança. A segurança no nível de aplicação torna-se mais viável nestes casos,

uma vez que, o elo seguro está presente na própria mensagem, transportada de um
2
ponto a outro, e não mais numa simples aplicação que troca mensagens com seu

usuário final.

Segurança é, sem duvida, um fator relevante para a utilização de sistemas

distribuídos. A media que novos serviços são disponibilizados, cada camada da

arquitetura necessita estar segura para manter a integridade do sistema todo.

1.3 Objetivo

Com o objetivo de demonstrar o funcionamento de Web Services seguros

utilizando a tecnologia Java, num primeiro momento será abordado o conceito da

arquitetura orientada a serviços, que propõe padrões e práticas de desenvolvimento

para possibilitar que serviços possam interagir adequadamente em ambientes

heterogêneos.

Aplicando esses conceitos em Web Services que constituem uma

arquitetura computacional distribuída baseada em serviços autodescritivos que

podem ser publicados, localizados e executados através da Web.

Web Services utilizam XML, como formato para troca de dados, e um

conjunto de padrões e protocolos aceito pelas industrias e fabricante de software

para integrar as aplicações e sistemas diversos. Para melhor entendimento será

descrito cada um desses protocolos que englobam Web Services como:

• Simple Object Access Protocol (SOAP)

• Web Services Description Language (WSDL)

• Universal Description Discovery and Integration (UDDI)

3
 Por fim, será aplicada a especificação WS-Security (IBM, 2002) em um

estudo de caso, demonstrando a utilização de alguns frameworks em Java como

Axis (AXIS, 2008) e CXF (CXF, 2008), que auxiliam e facilitam no desenvolvimento.

1.4 Organização do trabalho

O texto referente a este trabalho encontra-se dividido da seguinte forma:

Fundamentação Teórica (Capítulo 2): é feito uma abordagem dos

assuntos e de tecnologias referentes ao objetivo deste trabalho,

como Web Services, SOAP, frameworks existentes, WS-Security e

etc;

Estudo de Caso (Capítulo 3): implementação e desenvolvimento de

uma aplicação na qual demonstra o ciclo de vida de um Web

Services, bem como a demonstração de algumas técnicas de

segurança utilizando a especificação WS-Security;

Conclusão (Capítulo 4): serão apresentadas todas as

considerações e conclusões sobre este trabalho;

Detalhamento do Protótipo (Capítulo 4): detalhamento do

desenvolvimento do protótipo com apresentação de algumas classes e

código fonte;

4
2. FUNDAMENTAÇÃO TEÓRICA

Neste capítulo será feita uma abordagem dos assuntos e de tecnologias referentes

ao objetivo deste trabalho, como Web Services, SOAP, frameworks existentes, WS-

Security e etc;

2.1 Arquitetura Orientada a Serviços (SOA)

O termo Service-Oriented Architecture foi inicialmente proposto por

SCHULTE & NATIS (1996), então analistas do Gartner. Eles definiram SOA como

“uma configuração de computação multicamadas que ajudam as organizações

compartilhar lógica e dados através de múltiplas aplicações e modelos de uso”.

(BIANCHI apud SCHULTE & NATIS, 2007).

A Organization for the Advancement of Structured Information Standards -

OASIS (OASIS, 2006), define SOA da seguinte forma:

Arquitetura Orientada a Serviços (SOA) é um paradigma para

organização e utilização de competências distribuídas as quais estão
sob o controle de diferentes domínios proprietários. Ela fornece um
meio uniforme de oferecer, descobrir, interagir e usar capacidades
para produzir efeitos desejáveis consistentes com pré-condições e
expectativas mensuráveis. (OASIS, 2006).

SOA é um conjunto de negócios, processos, organizações, gonvernância,

e métodos técnicos para habilitar uma maior agilidade e vantagem competitiva e em

um ambiente de TI. Ela prove a flexibilidade para tratar processos de negócios bem

como o entendendo a infra-estrutura de TI como componentes que podem ser

reutilizados e recombinados por endereços compartilhando prioridades gerenciais.

Desta forma, na essência, SOA é o mapa que te guia na estrada da vantagem

competitiva (BIEBERSTEIN, 2006).

5
 Coloque como cenário um ambiente baseado em uma arquitetura de

software modular, onde todos os aplicativos são acessados por uma única interface

web e os sistemas utilizam dados uns dos outros e “conversam”

indiscriminadamente. Usuários acessam todos os programas de forma transparente,

utilizam qualquer informação, independentemente de onde ela tenha sido gerada.

Contextualizando Bianchi (2008) e como forma de caracterização, imagine

uma empresa de eletricidade tem a capacidade de gerar e distribuir eletricidade

(capacidade subjacente). A fiação da rede de distribuição da companhia elétrica (o

serviço) oferece o meio para fornecer eletricidade para suportar o uso por um

consumidor residencial típico (funcionalidade do serviço), e um consumidor acessa a

eletricidade gerada (a saída da invocação de serviço) via uma tomada de parede

(interface de serviço).

Para a utilizar a eletricidade, um consumidor precisa entender que tipo de

plug usar, qual a voltagem fornecida e quais os possíveis limites de carga; a

empresa presume que o consumidor irá conectar somente aparelhos adequados à

voltagem ofertada e à carga suportada ; e o consumidor por sua vez, assume que os

aparelhos adequados podem ser conectados sem danos ou riscos (suposições

técnicas do serviço).

Um usuário residencial ou comercial precisa abrir uma conta na empresa

para usar o fornecimento (restrição de serviço) e a empresa irá medir o consumo e

espera que o consumidor pague pela energia conforme taxa prevista (política de

serviço).

Quando o consumidor e a empresa concordam nas restrições e políticas

(contrato de serviço), o consumidor pode ter o fornecimento de eletricidade usando o

serviço desde que a rede de distribuição de eletricidade e a conexão residencial

6
permaneçam intactas (por exemplo, uma tempestade que derrube a rede e

interrompa o fornecimento) e o consumido pode pagar (por exemplo, transferência

eletrônica de fundos) a empresa (acessibilidade). Em certas situações (por exemplo,

demanda excessiva), uma empresa pode limitar o fornecimento ou instituir cortes

rotativos (políticas de serviço). utilizar

Uma implementação de SOA pode se empregar de qualquer tecnologia

padronizada baseada em web. Na maior parte, utilizam-se de web services que

incluem: XML, SOAP - protocolo baseado em XML utilizado para trocas de

informações , WSDL – descrição dos Web Services, UDDI – páginas amarelas

(BIEBERSTEIN, 2006).

2.2 Web Services

"Os Web Services surgiram no final da década de 90, quando alguns

fabricantes de middleware perceberam a necessidade de padronizar as

implementações de SOA que estavam surgindo. Isto era fundamental para garantir a

interoperabilidade de aplicações, sem a qual a visão de SOA não faria sentido"

(JAVA MAGAZINE, 2008).

Segundo Kreger (KREGER, 2001):

um Web Service é uma interface que descreve uma coleção de

operações que são acessíveis pela rede através de mensagens XML
padronizadas. Ele é um serviço descrito usando um padrão com uma
notação formal XML chamada de descrição do serviço. Esta
descrição cobre todos os detalhes necessários para interagir com o
serviço, incluindo os formatos das mensagens, os protocolos de
transporte e as localizações de cada serviço. A interface esconde os
detalhes da execução do serviço, permitindo que seja usado
independentemente da plataforma de hardware ou de software em
que esteja implementado e também independentemente da
linguagem de programação que foi escrita. Estas características
fazem com que as aplicações baseadas em Web Services sejam
fracamente acopladas e orientadas a serviços, facilitando o uso de
vários serviços em conjunto para executar operações complexas.
7
 "Um Web Service é uma aplicação lógica, programável, acessível, que usa

protocolos padrões da Internet, para que se torne possível a comunicação

transparente de máquina-para-máquina e aplicação-para-aplicação" (BOARO,

2008). São programas desenvolvidos para simplificar a comunicação entre

máquinas de redes diferentes.

Os Web Services são componentes de softwares que são chamados a

partir de outros aplicativos. São ‘páginas web’ para outros computadores e não para

seres humanos como as páginas HTML tradicionais (TOLOMELLI, 2008). É uma

tecnologia desenvolvida para que uma outra aplicação o utilize independente de

plataforma ou linguagem de programação, através de protocolos padronizados e

com transações transparentes para o usuário.

As chamadas às operações, incluindo os parâmetros de entrada/saída,

são codificadas no protocolo SOAP (Simple Object Access Protocol) baseado em

XML. Os serviços (operações, mensagens, parâmetros, etc.) são descritos usando a

linguagem WSDL (Web Services Description Language). O processo de

publicação/pesquisa/descoberta de Web Services utiliza o protocolo UDDI (Universal

Description, Discovery and Integration) (BIEBERSTEIN, 2006).

8
 Figura 1 - Mensagens trocadas na invocação de um Web Service. Fonte: ROSENBERG, 2004

2.3 XML

Segundo o W3C (2008), Web Services é uma solução utilizada na

integração de sistemas e na comunicação entre aplicações diferentes. Para a

representação e estruturação dos dados nas mensagens recebidas/enviadas é

utilizado o XML (eXtensible Markup Language).

Ainda segundo W3C (2000):

A linguagem XML foi desenvolvida como um profile de SGML

(Standard General Markup Language) designado principalmente para
aplicações Web. A partir dessa linguagem, é possível definir criar
extensões para linguagens de marcação, através do uso de novas
tags. Dados disponíveis em documentos XML são representados de
maneira semelhante à de uma fonte semi-estruturada. A flexibilidade
oferecida pela linguagem através da definição de novas tags e
aninhamento de elementos e a facilidade na troca de informação
entre fontes distintas a credenciam como o novo padrão para
estruturação, integração e troca de documentos na Internet.

9
 XML é um padrão da indústria de informática que tem como maior objetivo

o intercâmbio de dados. Ele permite que sistemas possam trocar informações de

uma forma mais abrangente que arquivos texto, já que podemos dar semântica aos

dados que estão sendo manipulados. Da mesma forma que HTML (Hyper Text

Markup Language), o XML se utilizam etiquetas para representar os dados; porém

existem várias diferenças entre esses dois padrões. Enquanto HTML especifica

como os dados devem ser exibidos, XML se preocupa com o significado dos dados

armazenados.

Uma linguagem de marcação é um mecanismo para identificar estruturas

em um documento. A especificação XML define uma forma padrão adicionar

marcação aos documentos. O XML é um conjunto de regras abstractas para a

construção de uma linguagem de marcação. XML não é uma linguagem de

marcação em si. XML foi projetado para descrever dados. Tags XML não são

predefinidas no XML. Você deve definir as suas próprias tags. XML usa um DTD

(Document Type Definition) ou XML schema para descrever os dados. DTD ou XML

schema é projetado para serem auto-descritivo (XYZWS, 2008).

XML é o bloco de construção básico de Web Services. Toda as

tecnologias recomendadas pelo WS-I Basic Profile 1.0 são constituídas sobre XML e

XSD (XML Shema Language).

2.4 SOAP

O protocolo SOAP é utilizado para os Web Services permitindo a troca de

informações em ambientes descentralizados e distribuídos. SOAP não se importa

com o sistema operacional, a linguagem de programação ou o modelo do objeto que

está sendo usado no lado do servidor ou no lado do cliente, este se comunica com
10
os sistemas usando o protocolo XML baseado em texto, em vez de um formato

binário usado pelos outros protocolos, isto o torna altamente interoperável por meio

de várias plataformas (GUNZER, 2002).

O Simple Object Access Protocol (SOAP) é um tipo de documento XML

que consite em três partes: um envelope que define um determinado domínio para

descrever o que está na mensagem e como deve ser processada, um conjunto de

regras de codificação para expressar a instancia dos tipos definidos na aplicação, e

uma convenção para representação da chamadas remotas(RPC) e suas respostas.

As mensagens SOAP são transportadas por vários tipos de protocolos de rede

como, SMTP, FTP e HTTP. Porem, o WS-I Basic Profile 1.0 recomenda o uso de

SOAP sobre HTTP (XYZWS, 2008).

SOAP quando usado com HTTP, trás vantagens como a facilidade de

atravessar firewalls, utilizando naturalmente HTTP request e HTTP response, alem

de ser mais simples quando comparado a outros protocolos como RMI, CORBA, and

DCOM.

De acordo com o W3Schools (W3S, 2008) a estrutura da mensagem

SOAP é definida em documento XML que contém os seguintes elementos:

• Envelope: Esse é o elemento raiz do SOAP e identifica o

documento XML como uma mensagem SOAP e é responsável por

definir o conteúdo da mensagem;

• Header (opcional): O cabeçalho, se presente, tipicamente contém

informações relacionadas à segurança, roteamento ou informações

ao destinatário de tratamento da mensagem;

• Corpo - Body: Contém as informações de chamada e de resposta

ao servidor;
11
 • Fault: Contém as informações dos erros ocorridos no envio da

mensagem. Esse elemento só aparece nas mensagens de resposta

do servidor.

Ainda segundo W3Schools (W3S, 2008), a mensagem SOAP possui o

seguinte esqueleto:

Figura 2 - Esqueleto mensagem SOAP. Fonte: XYZWS, 2008

Muitas vezes a mensagem transportada deve ser de conhecimento

somente dos seus receptores e necessita ser segura. O serviço remoto precisa

conhecer quem está requisitando seu serviço e se está autorizado. Muitos pacotes

necessitam descrever importantes informações sobre o que o pacote todo contém,

por exemplo: o remetente, como o receptor vai validar o remetente, quais

permissões o remetente possui e assim por diante. Isto, basicamente representa a

implementação de segurança na própria mensagem SOAP discutida mais adiante

(ROSENBERG, 2004).

12
 2.5 WSDL

Para invocar um contrato (ou seja, função) fornecido por um Web Service,

precisa-se saber de antemão como as mensagens SOAP são estruturados, qual

protocolo será utilizado, o endereço Internet do Web Service, o nome do contrato,

bem como o número de parâmetros e todos os seus tipos. WSDL representa um

contrato entre um provedor Web Service e seu consumidor na qual se especifica o

exato formato de mensagem, o protocolo Internet, o endereço na Internet do

fornecedor de serviços, etc.

Web Services Description Language (WSDL) é um formato XML para

descrever serviços de rede como um conjunto de parâmetros que operam nas

mensagens que contenham qualquer documento-orientado ou procedimento

orientado para informação. As operações e mensagens são descritas de forma

abstrata, e então ligadas em um protocolo de rede concreto e formato de mensagem

definidos em endpoint. Endpoints concretos são relacionados e combinados dentro

de endpoints abstratos (serviços). WSDL é extensível e permite descrição de

endpoints e suas mensagens independentemente do formato ou protocolo de rede

que são usados para comunicação, de qualquer forma, as únicas ligações descritas

no documento é a descrição de como usar WSDL em conjunto com SOAP 1.1,

HTTP GET/POST, e MIME (W3C, 2001).

Com WSDL, uma possível automatizar a geração de proxies para Web

Services em maneira que seja independente de linguagem e plataforma. JAX-RPC é

uma das tecnologias que podem interpretar um documento WSDL para gerar

interfaces e stubs para o seu Web Service.

Um documento WSDL descreve os serviços do Web Service através do

XML, fornecendo uma documentação do serviço para que possíveis clientes possam
13
utilizá-lo de forma automatizada. A WSDL apresenta a definição de um Web Service

em duas partes. A primeira representa uma definição abstrata independentemente

do protocolo de transporte de alto nível, enquanto a segunda representa uma

descrição da ligação específica para o transporte na rede (KREGER, 2001).

WSDL foi projetada de modo que ela possa expressar associações com

protocolos diferentes do SOAP, a nossa principal preocupação aqui é como se

relaciona com WSDL SOAP sobre HTTP.

Usando WSDL, um cliente pode localizar um serviço web e invocar

qualquer das suas funções disponíveis publicamente. Com ferramentas para WSDL,

você também pode automatizar esse processo, permitindo às aplicações facilmente

integrem novos serviços, com pouco ou nenhum código manual. WSDL, portanto,

representa um marco da arquitetura Web Services, porque fornece uma linguagem

comum para descrever serviços e uma plataforma para integrar os serviços

automaticamente.

Segundo XYZWS (2008) WSDL contem os seguintes elementos:

• Interface: Descreve todas as informações publicas, funções

disponiveis;

• Data type: Tipos de dados tanto para as mensagens de pedido

como suas respostas;

• Binding: Informações sobre o protocolo usando no transporte;

• Address: Dados da localização de determinado serviço.

WSDL documento não fornecem informações de segurança e Quality of

Service(QoS).

14
Figura 3 - Exemplo WSDL. Fonte: XYZWS, 2008

15
 2.6 UDDI

O Universal Description, Discovery, and Integration (UDDI) é uma

iniciativa da industria num esforço para criar um conjunto de ferramentas, em

plataforma independente, que facilite a descrição dos serviços, descobrimento de

negócios e integração de serviços de determinado negocio. UDDI inside no processo

de descobrimento da arquitetura orientada a serviços (XYZWS, 2008).

Segundo Gunzer (GUNZER, 2002) define a UDDI como um padrão

projetado para fornecer um diretório de busca para os negócios e seus serviços. Ele

atua como mediador do serviço, permitindo que os clientes requisitantes encontrem

um fornecedor do serviço apropriado. A sua implementação é semelhante a uma

lista telefônica formada pelas seguintes partes:

• Páginas amarelas: Contêm informações organizadas por categoria

específica do produto, ou por regiões geográficas.

• Páginas Brancas: Contêm informações sobre os fornecedores de

serviços, incluindo o endereço, o contato e os identificadores

conhecidos.

• Páginas Verdes: Contêm informações técnicas sobre os serviços

dos Web Services que são expostos pelo negócio.

Através desta estrutura a UDDI consegue definir a maneira de publicar e

descobrir as informações sobre os Web Services, descrevendo as funcionalidades

específicas do serviço disponibilizado, através de uma conexão com a Internet para

que outros softwares possam utilizá-lo.

16
 Figura 4 - UDDI em uma arquitetura orientada a serviços. Fonte: ROSENBERG, 2004

2.7 Frameworks

O início da evolução dos Web Services caracterizou pela velocidade das

especificações bastante superior à velocidade das aplicações práticas desses

padrões. Ficava praticamente impossível acompanhar o ritmo da documentação

gerada pelo consórcio gestor do grupo WS-I (Web Services Ineroperability

Organization) (JAVA MAGAZINE, 2008).

Assim os frameworks tem um papel muito importante e para demonstrar a

tecnologia usaremos dois frameworks de código aberto, baseado na linguagem Java

e no padrão XML, para construção de Web Services.

17
 2.7.1 Apache Axis

A Apache (AXIS, 2008) define o AXIS (Apache EXtensible Interaction

System) como:

um mecanismo de comunicação SOAP. Ele pode ser usado como

uma biblioteca do cliente para invocar os serviços SOAP disponíveis
em outra máquina ou como uma ferramenta no lado do servidor para
executar serviços acessíveis pelo SOAP. No lado do cliente ele
fornece uma API para invocar serviços do SOAP RPC emitindo e
recebendo mensagens através do protocolo SOAP. No lado do
servidor ele fornece um mecanismo para escrever e acessar serviços
RPC ou serviços de mensagens, que devem ser hospedados por um
servlet container.

O Axis é a versão 3.0 do Apache SOAP que começou na IBM com o

"SOAP4J" e tem o objetivo de ser um sistema mais flexível e capaz de assegurar o

tratamento do SOAP definido na especificação do protocolo de XML do W3C. A

versão atual do AXIS é escrita em Java, mas uma implementação em C++ no lado

do cliente do AXIS está sendo desenvolvida. Além de funções de suporte para o

SOAP, ele inclui também suporte extensivo para WSDL, possui ferramentas que

geram classes Java de um WSDL e uma ferramenta para monitorar pacotes TCP/IP.

O AXIS permite a separação entre os problemas de infra-estrutura e o

processamento do negócio devido ao fato da execução das tarefas de autenticação

e autorização serem executadas em seqüência antes de chamar os serviços de

negócio. Ele propicia o processamento específico de uma mensagem SOAP em

uma seqüência de operações através da aplicação de um modelo modular que

aceita as evoluções das especificações sem causar grandes impactos na arquitetura

da plataforma.

Segundo Java Magazine (2008) o Axis traz facilidades interessantes para

o desenvolvimento. Uma delas é o mapeamento de schemas XML para Java e de

Java para XML. Outras dignas de notas são as abstrações no uso de protocolo
18
SOAP e a compatibilidade com WSDL. Alem disso, por oferecer componentes da

toda a pilha WS-*, podemos utilizá-lo em um container web leve como Apache

Tomcat ou o Jetty, sem a necessidade de um servidor de aplicações Java EE

completo.

O Axis disponibiliza dois modos para "expor" os métodos de uma classe

através de web services. O modo mais simples utiliza os arquivos JWS (Java Web

Service) do Axis. O outro método utiliza um arquivo WSDD (Web Service

Deployment Descriptor), que descreve com detalhes como serão criados os web

services a partir dos recursos (classes Java) existentes. (AXIS, 2008).

2.7.2 Apache CXF

O projeto Apache CXF é a união entre os projetos XFire, framework para

Web Services e Celtix, framework para Enterprise Service Bus (ESB) e se torna hoje

um projeto maduro na Apache Foundation, deixando a Incubadora de lado para se

tornar um dos frameworks mais completos para a operabilidade de Web Services,

principalmente para arquiteturas SOA (CXF, 2008).

O objetivo do projeto CXF é ser um poderoso framework, oferecendo de

maneira fácil e intuitiva todas as funcionalidades implementas pelos os padrões JCP

para Web Services. Ele também simplifica a construção, integração e reuso flexível

de componentes de negócios usando as premissas da arquitetura orientada a

serviços.

Segundo Wikipedia (2008) as características chaves do CXF incluem:

• Clara separação do front-ends, como JAX-WS, do código;

• Simplicidade com a criação de clientes e endpoints sem anotações;

• Altar performance com o mínimo de overhead;

19
 • Integração de componente web service com Spring Framework e

Geronimo.

CXF é utilizado em muitos projetos SOA da própria Apache como Apache

ServiceMix, Apache Camel, e Apache ActiveMQ. Também existe um versão

enterprise do projeto chamada FUSE Services Framework que é testada, certificada

e suportada pela IONA Tecnologies.

Nas palavras de Felipe (2008) usando CXF, os serviços são definidos

usando contratos WSDL e são acessados por um numero diferente de formatos de

mensagens (bindings) e protocolos de redes (transports), incluindo SOAP sobre

HTTP, SOAP sobre JMS, XML sobre HTTP e XML sobre JMS. CXF prove uma

arquitetura plugavel que suporta tanto a ligação de tipos XML como não-XML,

combinando com qualquer tipo de transporte. Essa ampla range de combinação cria

uma maior flexibilidade e integração de Web Services e sistemas legados usando

esse framework.

2.8 Segurança em Web Services

Os mecanismos de segurança dos Web Services ainda estão sendo

discutidos. O SOAP, por exemplo, não define um mecanismo para autenticação de

uma mensagem antes que ela seja processada. Como solução é implementada a

segurança nos canais de transmissão usados para trocar as mensagens SOAP,

utilizando o HTTP com o SSL (Secure Socket Layer) ou as VPNs (Virtual Private

Networks). Também estão sendo desenvolvidos alguns mecanismos para manter a

segurança na camada de mensagens como a assinatura digital em XML, a

criptografia em XML e a SAML (Security Assertion Markup Language) que é uma

linguagem comum para compartilhamento de serviços de segurança.

20
 Um fator importante que deve ser considerado para a utilização dos Web

Services é que eles normalmente são transportados sobre o HTTP na porta 80 e

com isso passam facilmente pelo firewall situado entre a rede interna de uma

empresa e a Internet. O firewall monitora todo o tráfego de fora para dentro, e

bloqueia qualquer tráfego que não esteja autorizado, mas a porta 80 usualmente é

deixada com pouca proteção. Enquanto a CORBA e a Java RMI são utilizadas em

outras portas e têm o seu acesso dificultado, os Web Services têm a vantagem de

passar livremente pelo firewall, mas isto também pode se configurar em uma

desvantagem se o Web Service não implementar nenhuma funcionalidade de

segurança.

Os Web Services simplificaram as comunicações, mas também alteraram

algumas medidas de segurança existentes. Então, o desafio agora é definir um

modelo de segurança que demonstre como os dados podem ser transportados

através da aplicação e da rede de acordo com os requisitos especificados pelo

negócio sem expor os dados a um risco inadequado.

2.8.1 Análise das Ameaças Versus Mecanismos de Segurança

Na tabela abaixo estão relacionados as principais ameaças e ataques aos

Web Services, o tipo de segurança envolvida e os mecanismos de segurança que

procuram combater.

Tipo de
Ameaças e Ataques Mecanismos de Segurança
Segurança
Autenticação Autenticação de usuários através de
Acesso não autorizado
Não repúdio certificados digitais.
Manipulação de Privacidade Utilização de criptografia e
parâmetros Integridade assinaturas digitais nas mensagens.
Utilização da criptografia nas
Espionagem na rede Privacidade
camadas de transporte e aplicação.
21
 Autorizar acessos controlados aos
Divulgação dos dados de arquivos WSDL (configuração) e
Autorização
configuração tomar cuidados com o tratamento de
exceções do serviço Web.
Utilização de criptografia e
assinaturas digitais nas mensagens,
Privacidade
Repetição de mensagem além de utilizar uma identificação
Integridade
única de mensagens para evitar
duplicação.
Fonte: (WATHIER, 2005)

2.9 WS-Security

Em abril de 2002, a Microsoft Corporation, a IBM Corporation e a VeriSign

Inc. uniram-se e publicaram um conjunto de novas especificações de segurança

denominadas WS-Security para serviços Web, com o objetivo de que as empresas

pudessem criar e construir aplicações de serviços Web com ampla

interoperabilidade. Em março de 2004, uma nova especificação do padrão WS-

Security foi publicada, como Web Services Security: SOAP Message Security 1.0,

pelo grupo OASIS (Organization for the Advancement of Structured Information

Standards) que descreve avanços na mensagem SOAP, ao especificar um perfil no

uso da Assinatura XML (XML Signature) e da Criptografia XML (XML Encryption)

para garantir integridade e confidencialidade para mensagens SOAP (OASIS, 2005).

WS-Security suporta, integra e unifica vários modelos, mecanismos e

tecnologias de segurança em uso no mercado, permitindo que vários sistemas

possam interoperar em plataformas e linguagens neutras.

Para cada framework existe uma maneira diferente de implementar a

especificação WS-Security. “WS-Security oferece os mecanismos-padrão de

segurança necessários para realizar o intercâmbio seguro de mensagens

certificadas” (IBM, 2002). Essa especificação define como usar encriptação XML e

22
assinatura XML no SOAP para tornar segura a troca de mensagens, como uma

alternativa ou extensão do uso do protocolo HTTPS para assegurar o canal num

ambiente de Web Services.

2.9.1 XML Encryption

XML Encryption provê segurança no nível de privacidade por cifrar os

dados evitando que terceiros vejam seu conteúdo. A segurança é realizada ponto a

ponto para aplicações que requerem trocas seguras de dados estruturados.

Criptografia baseada em XML é o caminho natural para segurança com troca de

dados entre aplicações complexas.

Transport Layer Security (TSL) é de fato o padrão de comunicação segura

na internet e é um protocolo de segurança ponto a ponto que segue o famoso

Secure Socket Layer (SSL). XML Encryption não pretende substituir SSL/TSL, mas

prover um mecanismo para requisitos de segurança que não é coberto pelo SSL

como:

• Criptografar parte dos dados;

• Sessão segura entre mais de duas partes (WATHIER, 2008).

Com XML Encryption, cada parte pode manter estado de segurança ou

não com qualquer das partes comunicantes. Ambos dados seguros ou não podem

ser trocados no mesmo documento.

XML Encryption pode manusear dados no formato XML ou não (binário).

Para mensagens XML, essa sintaxe foi complementada para uso em mensagens

SOAP pelo WS-Security.

23
 2.9.2 XML Signature

Segundo Varchavsky (2008), a assinatura digital é um método com o

objetivo de dar ao receptor a certeza de que um texto foi criado por determinada

entidade e que não foi alterado. O processo consiste em obter o resumo do texto

aplicando-o a uma função Hash e, em seguida, criptografar esse resumo com a

chave privada do assinante. O receptor deve calcular o resumo do texto pela mesma

função de Hash e compará-lo com o resumo enviado, já descriptografado com a

chave pública do assinante. A certeza da não alteração do texto e da identidade do

assinante é obtida se os dois resumos forem iguais. Isso se não houver nenhum

outro roubo de chaves.

Assim como para a criptografia, existe uma especificação para a

assinatura digital em documento XML, o padrão XML Signature, que também é

adaptado para mensagens SOAP pelo padrão WS-Security.

A assinatura digital em XML é um padrão seguro para verificar as origens

das mensagens. A especificação da assinatura em XML permite que os documentos

XML sejam assinados de uma forma padrão, com uma variedade de algoritmos de

assinatura digitais diferentes. As assinaturas digitais podem ser usadas para

validação das mensagens e para o não-repúdio (ICP-BRASIL, 2008).

2.9.3 SAML

A SAML (Security Assertion Markup Language) é o primeiro padrão da

indústria para as transações seguras de comércio eletrônico que usam XML. O

SAML está sendo desenvolvido para fornecer uma linguagem comum para

compartilhar serviços de segurança entre as empresas engajadas no business-to-

business e nas transações business-to-consumer. O SAML permite que as

24
empresas troquem de forma segura autenticação, autorização e informações de

perfil entre seus clientes e parceiros considerando seus sistemas de segurança ou

suas plataformas de e-commerce. Como resultado a SAML promove a

interoperabilidade entre os diferentes sistemas de segurança, fornecendo a estrutura

para transações seguras do e-business através das fronteiras da empresa

(AMORIM, 2004).

25
3. ESTUDO DE CASO

Neste capítulo são apresentados a implementação e desenvolvimento de uma

aplicação na qual demonstra o ciclo de vida de um Web Services, bem como a

demonstração de algumas técnicas de segurança utilizando a especificação WS-

Security.

3.1 Visão Geral

Os Web Services em geral tornaram-se muito conhecidos devido ao seu

poder de comunicação entre aplicações. Mas como controlar a segurança de uma

solução tão versátil mas que ao mesmo tempo fica exposta na web? Foi pensando

nisso que o W3C criou padrões a mais de segurança para os Web Services, o WS-

Security (W3C, 2008).

O WS-Security é um padrão especificado pelo W3C. É uma nova

linguagem formada por tags para serem inseridas no cabeçalho da mensagem

SOAP, funcionando como uma extensão SOAP.

O SOAP foi de fato desenvolvido prevendo sua ampliação para incluir

futuros recurso. Dai o cabeçalho da mensagem, que foi visto anteriormente. Neste

cabeçalho é transmitido tags especificas com informações adicionais sobre a

comunicação.

Um exemplo dessas informações adicionais é a transmissão de login e

senha de usuários(Usertoken). É ai que entra a necessidade da padronização. Uma

aplicação cliente pode inserir login e senha de usuário no cabeçalho da mensagem.

O servidor lê a informação e autentica.

A questão é que o formato que for utilizado pelo cliente precisa ser

corretamente interpretado pelo servidor. Então torna-se necessário um padrão para

26
isso: WS-Security. O WS-Security define o padrão de nomes de tags que serão

utilizadas para transmitir dados de autenticação, entre outras informações de

segurança.

É ai que entra a extensibilidade do XML e, consequentemente, do SOAP.

O SOAP tem um namespace, as tags pertencem a ele. Mas pode-se adicionar na

raiz do documento outros namespaces, como por exemplo do WS-Security, assim a

inserção de tags do WS-Security dentro do cabeçalho da mensagem é possível. A

mensagem assim passa a envolver mais de uma linguagem, mais de um

namespace, essa é a grande vantagem da extensibilidade do XML.

A questão é que, para o padrão, a forma como o documento é construído

não importa em nada. Cabe a cada fabricante criar simplificações, toolkits, para que

o programador não tenha que recorrer ao nível mais baixo de montagem: a

concatenação de texto.

Desta forma a Apache criou os frameworks Axis (AXIS, 2008) e CXF

(CXF, 2008). O WSS4J (2008) se agrega aos frameworks permitindo a criação de

Web Services seguros, implementando o protocolo WS-Security, entre outros.

Segundo Varchavsky (VARCHAVSKY, 2008) define WSS4J como:

é uma implementação em Java da Apache para o padrão WS-

Security, incluindo a especificação principal, o Username Token
Profile e o X.509 Token Profile, além de outros profiles
implementados parcialmente. A utilização direta do WSS4J é
dificultada pela complexidade da API e pela pouca documentação
disponível. A melhor forma de usar a biblioteca é através dos
frameworks de Web Services da própria Apache Axis, Axis2 e CXF,
que disponibilizam uma interface para utilização bem mais
simplificada e feita de forma quase toda declarativa.

WSS4J pode gerar e processar as seguintes ligações em SOAP:

• XML Security

• XML Signature
27
 • XML Encryption

• Tokens

• Username Tokens

• Timestamps

• SAML Tokens

WSS4J suporta certificados no formato X.509 e cadeias de certificados

(WSS4J, 2008).

3.2 Pré-requisitos

A plataforma utilizada para o desenvolvimento da aplicação é o J2EE

(Java 2 Enterprise Edition), utilizando o JDK (Java Development Kit) 1.5.0.15. Para

servidor WEB utiliza-se o Jetty. A ferramenta IDE que auxilia o desenvolvimento da

aplicações é o Eclipse Europa 3.3.2 rodando no sistema operacional Ubuntu 8.04,

juntamente com o browser Mozilla Firefox 3.0.3. A versão do framework CXF é 2.1.1

e do Apache Axis 1.4.

Como primeiro passo são criados três projetos Java, através da opção File

> New > Java Project na ferramenta Eclipse.

Um chamado Server, um Client e o ultimo Terceiro, para cada projeto é

criado na raiz do mesmo uma pasta chamada lib, no qual é destinada a receber as

bibliotecas dos frameworks utilizados. Todos os jars da pasta devem ser adicionados

ao classpath dos respectivos projetos.

O projeto Server faz o papel de servidor que recebe as chamados dos

clientes Web Services, também conhecidos como Web Services consumidor. Ele

também é desenvolvido com recursos do CXF e recebe os seguintes jars

encontrados no próprio framework:

28
activation-1.1.1.jar, antlr-2.7.6.jar, aopalliance-1.0.jar, asm-2.2.3.jar, asm-attrs-1.5.3.jar,
bcprov-jdk15-138.jar, bsh-2.0b4.jar, cglib-nodep-2.1_3.jar, commons-beanutils-
1.7.0.jar, commons-codec-1.3.jar, commons-collections-3.2.jar, commons-dbcp-1.2.jar,
commons-digester-1.8.jar, commons-discovery-0.4.jar, commons-lang-2.2.jar,
commons-logging-1.1.1.jar, cxf-2.1.1.jar, dom.jar, dom4j-1.6.1.jar, ehcache-1.2.3.jar,
ezmorph-1.0.4.jar, FastInfoset-1.2.2.jar, geronimo-annotation_1.0_spec-1.1.1.jar,
geronimo-servlet_2.5_spec-1.2.jar, geronimo-ws-metadata_2.0_spec-1.1.2.jar, jaxb-api-
2.1.jar, jaxb-impl-2.1.6.jar, jaxb-xjc.jar, jaxp-api.jar, jaxws-api-2.1-1.jar, jetty-6.1.9.jar,
jetty-util-6.1.9.jar, jta-1.0.1B.jar, log4j-1.2.13.jar, mail-1.4.1.jar, neethi-2.0.4.jar,
opensaml-1.1.jar, poi-3.0.1-FINAL-20070705.jar, saaj-api-1.3.jar, saaj-impl-1.3.jar,
sax.jar, slf4j-api-1.3.1.jar, slf4j-jdk14-1.3.1.jar, standard.jar, stax-api-1.0.1.jar, stax-utils-
20060502.jar, wsdl4j-1.6.1.jar, wss4j-1.5.4.jar, wstx-asl-3.2.4.jar, xalan-2.7.0.jar,
xerces.jar, xercesImpl.jar, xmldsig.jar, xml-resolver-1.2.jar, XmlSchema-1.4.2.jar,
xmlsec.jar, xmlsec-1.4.0.jar

O projeto Client, como o próprio nome diz é responsável por fazer a

solicitação ao servidor, também implementado utilizando o framework CXF e recebe

as mesmas bibliotecas do projeto Server.

Já o projeto Terceiro, como forma de estudo, a implementação é baseada

no framework Axis. A IDE Eclipse fornece os jars necessários para o Axis na própria

ferramenta, porém mais algumas bibliotecas foram adicionadas para o uso do

padrão WS-Security conforme consta na figura abaixo:

Figura 5 - Lista dos jars do projeto Terceiro

29
 3.3 Implementando os Web Services

No projeto Server uma classe é criada com a anotação @WebService, e

dentro dessa classe é descrito o endereço do serviço através de uma variável

estática, assim como, o metodo getMensagem, que é consumido pelo cliente e o

método main, que é responsável por executar a classe e publicar o serviço.

Figura 6 - Classe Servidor projeto Server

Ao ser executada a classe, o servidor Jetty é iniciado e o CXF encarrega-

se de publicar o Web Service. Para conferir, basta entrar pelo navegador no

endereço descrito na classe mais o parâmetro ?wsdl e o resultado é o wsdl do

serviço.

30
 Figura 7 - WSDL do serviço

Uma vez que o serviço esta ativo e tem-se o wsdl, é possível a geração de

Stub no projeto Client. "Um Stub é um Proxy para o serviço, uma classe utilizada

diretamente pelo cliente como se fosse o serviço, mas que encapsula o real acesso

remoto a ele" (VARCHAVSKY, 2008).

Para isso é utilizado o utilitário wsdl2java que vem com o CXF. Sua

utilização é simples, basta setar a variável de ambiente JAVA_HOME, e executar o

comando wsdl2java -d [diretorio que vai jogar as classes geradas] [endereço do

wsdl].

31
 Após a execução, basta atualizar o projeto Client e as classes geradas

podem ser visualizadas no diretório src do projeto. Uma classe Cliente é criada e no

seu método main é utilizado os stubs gerados e como saída o retorno do método

invocado do Web Service do projeto Server.

Figura 8 - Classe Cliente projeto Client com o retorno da execução

Voltando ao projeto Terceiro, é gerado também um cliente para consumir

o Web Service. O Eclipse já traz um plugin que ajuda bastante na criação dos stubs

para o Axis. Basta clicar com o botão direito no projeto e escolher as opções New >

Other... > Web Service client. Uma janela com o campo para colocar o endereço

wsdl e algumas opções para geração são mostrados e quando clicado em Finish o

plugin encarrega-se de fazer todo o trabalho.

32
 Figura 9 - Plugin do Eclipse gerar stub Axis

Como a opção selecionada é de não geração de "test client", uma Classe

para instanciar o stub também é criada.

Figura 10 - Classe Terceiro do projeto utilizando framework Axis

33
 Como forma de monitoramento, neste trabalho é adicionado duas linhas

na classe stub br.cesumar.ServidorServiceSoapBindingStub ao final do método

getMensagem:

.... _call.invoke(new java.lang.Object[] {});

System.out.println("SOAP Request: "+
_call.getMessageContext().getRequestMessage().getSOAPPartAsString());
System.out.println("SOAP Response:
"+_call.getMessageContext().getResponseMessage().getSOAPPartAsString());

Isso faz com que todas as mensagens SOAP enviadas e recebidas ao

consumir o Web Service sejam lançadas na saída do console.

Neste momento o ambiente para implantação de um Web Services e seu

consumo estão completo. Os dois clientes invocam o serviço que responde

normalmente fechando seu ciclo de vida. Porém, se isso fosse um ambiente de

produção e cada parte estivesse em redes distintas e não protegidas, uma ação de

invasão certamente teria sucesso.

Nas próximas sessões, o desafio é evitar ou ao menos dificultar esse

ataque, implementado os processo de autenticação, criptografia e assinatura digital.

3.4 Autenticação

Varchavsky (2008) comenta que o processo de autenticação simples por

senha, o usuário fornece ao servidor um identificador e uma senha. O servidor

verifica se a senha fornecida corresponde à senha armazenada para tal

identificador. Para o caso de Web Services, o cliente vai inserir essas informações

na mensagem sendo enviada ao serviço. A inserção dessas informações,

obedecendo à especificação WS-Security, é feita no cabeçalho da mensagem SOAP

34
em um elemento UsernameToken, sendo nesse caso simples de envio definido na

especificação.

É importante lembrar que se as partes (servidor e cliente) combinarem que

mandar a informação de login, o processo de autenticação pode ser realizado,

muitas vezes no próprio corpo da mensagem SOAP. Mas imagine a dificuldade do

servidor ficar tratando varias exceções onde cada desenvolvedor tem sua maneira

de mandar o usuário e senha. É neste cenário que destaca-se a importância da

padronização proposto pelo WS-Security.

Outro fato é a exposição das informações de autenticação de um modo

claro, uma vez que o texto esta numa mensagem SOAP e monitorar e inteceptar

isso é algo fácil. A especificações WS-Security define a utilização da função SHA-1

como função de Hash para criação de password digest. O que acaba escondendo a

senha mas não elimina a possibilidade em que uma mensagem possa ser

reutilizada.

Para evitar esse tipo de ataque, é possível fazer o uso e um

nonce(Number Used Once), que é uma informação gerada aleatoriamente para ser

usada uma única vez. Nesse controle de utilização, a verificação se um determinado

nonce já foi utilizado é feita no servidor que recebe as requisições. Então isso pode

causar um outro tipo de problema, caso o numero de pedidos for grande e o servidor

tem problema de performance para gerenciar isso.

Uma terceira informação então, é gerada para contornar esse tipo de

problema. O uso de timestamp faz com que o servidor possa descartar o nonce com

base no período informado.

Para realizar esse tipo de segurança o CXF utiliza interceptor que são

invocados imediatamente antes ou depois da chamada de um serviço.

35
 Para isso, na raiz do projeto Server é criado um arquivo de propriedades

que serve de configuração para o interceptor saber que mecanismo de segurança a

mensagem SOAP deve ter. O conteúdo desse arquivo é descrito abaixo:

action = UsernameToken
passwordType = PasswordDigest
passwordCallbackClass = br.cesumar.ServerCallbackHandler

Uma classe que implementa um callbackhandler do JAAS (Java

Authentication and Authorization Service), recebeu um callback, objeto no qual deve

ser verificado a senha do usuário. A classe ServerCallbackHandler é mostrada a

seguir:

Figura 11 - Classe ServerCallbackHandler projeto Server

Em seguida é criada a classe do interceptor responsável por verificar o

nonce e o timestamp enviados no cabeçalho da mensagem SOAP do cliente:

36
 Figura 12 - Classe UsernameTokenInterceptor

Algumas alterações na classe que publica o serviço são realizadas para

acoplar o interceptor ao serviço:

Figura 13 - Alterações na classe Servidor

37
 Após reiniciar o servidor, os projetos Client e Terceiro não mais

conseguem consumir o serviço e uma exceção é disparada nos projetos.

Voltando ao projeto Client é realizado um processo análogo ao Server

para que o mesmo passe a utilizar autenticação. Assim um arquivo

wss4jout.properties também é criado:

action = UsernameToken
user = client_cxf
passwordType = PasswordDigest
passwordCallbackClass = br.cesumar.test.ClienteCallbackHandler

Cria-se uma classe ClienteCallbackHandler responsável por setar a

senha:

Figura 14 - Implementação CallbackHandler no projeto Client

Ao final o arquivo de propriedades é acoplado a chamada do Web

Services Cliente, acidionando a lista de interceptors.

38
 Figura 15 - Alterações para autenticação na classe Cliente

Para o projeto Terceiro, como também utiliza o WSS4J, é criado um

arquivo responsável pelas configurações. No caso do Axis, o arquivo está

estruturado no formato XML, mas as informações são muito semelhantes ao arquivo

de propriedades do CXF.

Figura 16 - Arquivo wsdd responsável pelas configurações no Axis

39
 Perceba que também é utilizado um callbackHandler, e a mesma classe

utilizada no projeto Client é copiada para o projeto Terceiro, alterando apenas o

valor da senha enviada com o usuário.

passwordCallback.setPassword("senha_user_axis");

No Axis, o arquivo wsdd é passado como parâmetro para o stub, e sua

alteração na classe que consome o serviço é ainda menor:

Figura 17 - Alterações para autenticação na classe Terceiro

Feitas as modificações cada cliente passa a consumir o serviço passando

o usuário e senha de seus respectivos projetos. A aplicação Server pode tratar a

resposta para cada tipo de cliente se quiser. Ou até mesmo bloquear determinado

acesso a algum recurso.

O processo completo de autenticação que foi descrito encontra-se

implementado. Os dois clientes estão consumindo o serviço e qualquer alteração de

configuração, como troca de usuário ou senha, fará com que a tentativa não retorne

sucesso. É importante dizer que há um bug de segurança quando o cliente utiliza a

opção de PasswordText e isso é tratado no Web Service Server lançando uma

exceção para contornar esse problema.

40
 Figura 18 - Soap request e resultado da chamada Web Service com autenticação

3.5 Criptografia

"A palavra criptografia vem do grego, kriptós = escondido, oculto e grápho

= grafia, e é a arte ou ciência de escrever em cifra ou em códigos, de forma a

permitir que somente o destinatário a decifre e compreenda" (ICP-BRASIL, 2008).

A criptografia nasceu da necessidade de manter a privacidade de

informações. Desde a Antigüidade já se tinha conhecimento da criptografia, que era

utilizada a substituição ou troca de símbolos com o objetivo de confundir um possível

interceptador das mensagens. Para a computação esse princípio é mantido, porém a

escrita é substituída pelo processamento digital das informações e com a

capacidade de processamento de dados desta tecnologia, a criptografia tomou corpo

e desenvolveu-se (ICP-BRASIL, 2008).

41
 Os tipos de criptografia com base em algoritmos são basicamente

divididos em dois: Criptografia de chaves simétricas, e Criptografia de chaves

assimétricas.

A criptografia simétrica envolve o uso de uma chave secreta conhecida

apenas pelos participantes da comunicação segura. O emissor criptografa a

mensagem com esta chave, conhecida apenas por ele e por seu destinatário, e

envia a mensagem criptografada para o destinatário. O destinatário, de posse da

mesma chave, descriptografa a mensagem e tem acesso ao conteúdo desta

(ROSENBERG, 2004).

Figura 19 - Processo de criptografia simétrico. Fonte: ROSENBERG, 2004

Na criptografia assimétrica, a chave usada para criptografar é diferente da

usada para descriptografar. Um receptor que deseja receber uma mensagem divulga

a chave usada para criptografar, conhecida como chave pública, e guarda para si a

chave usada para descriptografar, chamada de chave privada. A eficácia do

processo vem da inviabilidade de se obter uma delas com base na outra. Assim,

qualquer um pode usar a chave pública para enviar o texto, mas somente aquele

que possui a chave privada pode descriptografá-lo. A principal desvantagem da

42
criptografia assimétrica é a complexidade computacional que torna o processo de

cifragem lento para grandes textos (VARCHAVSKY, 2008).

Figura 20 - Processo de criptografia assimétrico. Fonte: ROSENBERG, 2004

Neste presente estudo de caso, é implementado um processo misto entre

os dois tipos de criptografia. Onde à assimétrica é utilizada para criptografar uma

chave curta que é então usada na criptografia dos textos completos.

O primeiro passo é geração do par de chaves através da ferramenta

Keytool disponível no JDK da Sun usando o seguinte comando:

keytool -genkey -alias server -keyalg RSA -keystore serverkeystore.jks

O argumento genkey é utilizado para informar que deve ser gerado o par

de chaves correspondente ao certificado. O alias é a descrição das chaves que

serão armazenadas no repositório. O keylalg informa qual o algoritmo deve ser

utilizado para assinatura. Depois de executado o comando, é necessário informar a

senha do repositório do par de chaves e dados do certificado tais como: CN

=Commom Name (Nome do titular), O = Organization (Organização), OU =

Organization Unit (Unidade Organizacional), L = Location (Localização), S = State

(Estado) e C = Country (País). Depois de digitado esses dados, é criado um arquivo

43
com o nome serverkeystore.jks, que é o repositório onde está o par de chaves

gerado e o certificado.

Figura 21 - Gerar par de chaves pelo Keytool

O segundo passo é criar os outros repositórios que são responsáveis por

armazenar os pares de chaves dos clientes CXF e Axis. Utilizando o mesmo

processo que foi usado para o Server, mudando os parâmetros alias e keystore e

adicionando o parâmetro keypass:

keytool -genkey -alias client_cxf -keyalg RSA -keystore clientCXFkeystore.jks -

keypass senha_user_cxf
keytool -genkey -alias client_axis -keyalg RSA -keystore clientAxiskeystore.jks -
keypass senha_user_axis

O passo realizado a seguir é a troca da chave publica de ambos os

serviços. Para isso, deve-se executar os seguintes comandos:

keytool -export -alias server -keystore serverkeystore.jks -file public_key_server.cer

keytool -export -alias client_cxf -keystore clientCXFkeystore.jks -file
public_key_clientCXF.cer
keytool -export -alias client_axis -keystore clientAxiskeystore.jks -file
public_key_clientAxis.cer

44
 Os comandos geram três arquivos com o certificado de cada keystore.

Estes arquivos devem ser importados para o repositório do serviço que irá

comunicar.

keytool -import -alias server -keystore clientCXFkeystore.jks -file

public_key_server.cer
keytool -import -alias server -keystore clientAxiskeystore.jks -file
public_key_server.cer
keytool -import -alias client_cxf -keystore serverkeystore.jks -file
public_key_clientCXF.cer
keytool -import -alias client_axis -keystore serverkeystore.jks -file
public_key_clientAxis.cer

O argumento import informa que o certificado deve ser importado para o

repositório especificado no argumento keystore, que por sua vez informa qual o

nome do repositório. O argumento file informa qual o nome do certificado a ser

importado.

Por fim, o arquivo serverkeystore.jks é movido para a raiz do projeto

Server, e o arquivo clientCXFkeystore.jks para o projeto Client e

clientAxiskeystore.jks para o projeto Terceiro.

Voltando ao projeto Server é alterado o arquivo wss4jin.properties que

passa a ficar assim:

action = UsernameToken Encrypt

passwordType = PasswordDigest
passwordCallbackClass = br.cesumar.ServerCallbackHandler
decryptionPropFile = encryption.properties

E o arquivo encryption.properties é criado e colocado na raiz do projeto

junto com o wss4jin.properties e é definido com as seguintes propriedades:

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.M
erlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=senhajks
org.apache.ws.security.crypto.merlin.keystore.alias=server
org.apache.ws.security.crypto.merlin.file=serverkeystore.jks

45
 Como não foi indicado um callback handler específico para obter a senha

das chaves no keystore, o WSS4JINterceptor vai procurá-lo na classe indicada na

propriedade passwordCallbackClass, no caso br.cesumar.ServerCallbackHandler.

Nessa classe é acrescentado o par "alias" e "senha" do keystore.

senhas.put("server", "senhajks");

No projeto Client, o arquivo wss4jout.properties sofre as seguintes

alterações.

action = UsernameToken Encrypt

user = usuario_cxf
passwordType = PasswordDigest
passwordCallbackClass = br.cesumar.test.ClienteCallbackHandler
encryptionPropFile = encryption.properties
encryptionUser = server
EmbeddedKeyCallbackClass = br.cesumar.test.KeystoreCallbackHandler

Uma propriedade em especial, a EmbeddedKeyCallbackClass, aponta

para uma classe idêntica a implementada para a propriedade

passwordCallbackClass, a classe ClienteCallbackHandler então é copiada, somente

fornecendo a senha do keystore ao invés da senha do usuário.

Tambem é criado o arquivo encryption.properties, definido como:

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.M
erlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=senhajks
org.apache.ws.security.crypto.merlin.keystore.alias=server
org.apache.ws.security.crypto.merlin.file=clientCXFkeystore.jks

Para o projeto Teceiro, o processo é ainda mais simples, basta copiar o

arquivo encryption.properties do projeto Cliente e setar o keystore do projeto:

org.apache.ws.security.crypto.merlin.file=clientAxiskeystore.jks

46
 E seguida modifique o arquivo wssd para que fique com as novas

configurações:

Figura 22 - Arquivo wsdd alterado para criptografar a mensagem

Executando os projetos novamente, o criptografia da mensagem SOAP é

feita e seu corpo torna-se ilegível e no cabeçalho estão as informações relativas ao

processo de cifragem.

Figura 23 - Soap request e resultado da chamada Web Service com criptografia

47
 3.6 Assinatura Digital

A criptografia de chave assimétrica ou de chave pública ajuda a resolver o

problema de distribuição de chaves. Também resolve duas outras questões

relacionadas à criptografia: autenticação e não-repúdio. A autenticação permite que

alguém no mundo eletrônico confirme dados e identidades e o não repúdio impede

que pessoas retifiquem sua palavra eletrônica. Uma maneira de implementar esses

recursos é utilizar uma assinatura digital (ICP-BRASIL, 2008).

Quando a mensagem chega até o receptor, este utiliza a chave pública do

emissor para decodificar a assinatura digital. Se esse processo for realizado com

sucesso, então a informação é realmente autêntica, pois se a chave pública do

emissor decodificou a assinatura digital, significa que foi codificada com uma chave

privada correspondente que somente o emissor possui. Depois que esse primeiro

processo é validado com sucesso, pode-se validar a integridade, através da

comparação do Hash obtido da validação da assinatura digital com o hash obtido da

mensagem original. Se forem iguais, significa que a mensagem não foi alterada. A

figura abaixo ilustra como essas validações são realizadas (ROSEMBERG, 2004).

Figura 24 - Processo de assinatura digital. Fonte: ROSENBERG, 2004

48
 Figura 25 - Processo de verificação da assinatura digital. Fonte: ROSENBERG, 2004

Para realizar esse processo no projeto Server é adicionado mais alguns

parâmetros no arquivo wss4jin.properties:

action = UsernameToken Encrypt Signature

passwordType = PasswordDigest
passwordCallbackClass = br.cesumar.ServerCallbackHandler
decryptionPropFile = encryption.properties
signaturePropFile = signature.properties
EmbeddedKeyCallbackClass = br.cesumar.KeystoreCallbackHandler

Uma dessas propriedades aponta para uma classe

KeystoreCallbackHandler.java, que é igual a classe utilizada anteriormente no

projeto Client, então basta copiá-la para o projeto Server.

Por fim, o arquivo com as propriedades da assinatura digital é colocado na

diretório raiz do projeto.

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.M
erlin
org.apache.ws.security.crypto.merlin.keystore.type=jks

49
org.apache.ws.security.crypto.merlin.keystore.password=senhajks
org.apache.ws.security.crypto.merlin.file=serverkeystore.jks

No projeto Client o arquivo wss4jout.properties recebe os parâmetros para

realizar da assinatura digital:

action = UsernameToken Encrypt Signature

user = usuario_cxf
passwordType = PasswordDigest
passwordCallbackClass = br.cesumar.test.ClienteCallbackHandler
encryptionPropFile = encryption.properties
encryptionUser = server
EmbeddedKeyCallbackClass = br.cesumar.test.KeystoreCallbackHandler
signaturePropFile = signature.properties

Falta agora colocar o arquivo signature.properties e executar o projeto

para que a mensagem SOAP passe a ser assinada digitalmente.

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.M
erlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=senhajks
org.apache.ws.security.crypto.merlin.keystore.alias=client_cxf
org.apache.ws.security.crypto.merlin.file=clientCXFkeystore.jks

O ultimo passo é realizado no projeto Terceiro, alterando o arquivo wssd

para receber as novas configurações:

Figura 26 - Arquivo wsdd alterado para assinar digitalmente a mensagem

50
 Copia-se o arquivo signature.properties do projeto Cliente colocando as

configurações compatíveis do projeto:

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.M
erlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=senhajks
org.apache.ws.security.crypto.merlin.keystore.alias=client_axis
org.apache.ws.security.crypto.merlin.file=clientAxiskeystore.jks

Pronto. A implementação da assinatura digital na mensagem SOAP é

testada executando os projetos com as novas modificações, finalizando assim o

estudo de caso.

Figura 27 - Parte da mensagem SOAP utilizando o processo de assinatura digital

51
4. CONCLUSÃO

Os Web Services se tornaram muito populares nos últimos anos, devido a

sua arquitetura apresentar vantagens na integração de aplicações distintas e

distribuídas, inclusive aplicações legadas. Muitas vezes, esse tipo de solução utiliza-

se da infra-estrutura pública da Internet como meio de comunicação. Neste ponto

surge uma maior preocupação quanto a segurança, uma vez que, esses serviços

ficam expostos e as informações trocadas entre os usuários precisam ser

protegidas.

A especificação WS-Security vem de encontro com essa necessidade,

pois trata-se de uma forma de padronização dos mecanismos de segurança já

existentes como autenticação, criptografia, etc., agregando uma camada segura aos

Web Services a nível de aplicação. É importante ressaltar aqui que, a utilização de

determinada estratégia de segurança, adotada em nível de transporte e/ou de rede,

são fatores que devem ser vistos mas que em determinadas soluções, outros níveis

de segurança tornam-se mais viáveis.

O mercado também acompanha isso e aos poucos desenvolve novas

soluções para cada tipo de necessidade, como é o caso da Apache Foundation que

criou os frameworks Axis e CXF.

Assim neste presente trabalho, foi apresentado o funcionamento desses

frameworks, demonstrando algumas técnicas básicas de segurança utilizadas na

identificação de usuários, na proteção das mensagens trocadas e comprovação da

mensagem enviada pelo seu emitente. Toda a implementação foi feita com base no

padrão WS-Security, para facilitar a integração com outros sistemas e que pode ser

abordado em trabalhos futuros.

52
 O tema pesquisado aborda tecnologias recentes, como Web Services,

assim houve uma maior dificuldade na busca de informações, pois trata-se de

assuntos complexos e que ainda estão sendo discutidos pela comunidade. Em

alguns casos, valeu-se da experiência de outros projetos já executados em áreas

co-relacionadas para se resolver determinado problema.

Boa parte da implementação foi feita de forma declarativa, porem a troca

por um modelo que utiliza classes é possível e pode ser feita pesquisando mais a

fundo a documentação do WSS4J. Ainda sobre o WSS4J percebe-se que

configurações utilizadas tanto no CXF como no Axis são bastante idênticas e um

processo de migração pode ser facilitado.

Dentre muitos fatores apresentados da tecnologia Java, é importante

ressaltar a sua capacidade de integração e as diversas aplicabilidades que em

conjunto com outras tecnologias podem proporcionar a nível de desenvolvimento,

diminuindo consideravelmente o número de linhas programadas, deixando o código

fonte mais enxuto e facilitando sua manutenção. Grande parte disso deve-se a

utilização de frameworks e bibliotecas fornecidas de forma livre.

Ao final e com base na pesquisa realizada para elaboração deste trabalho,

percebe-se que os grandes playes do mercados estão trabalhando para que

integração entre organizações, aplicações e processos de negócios seja realizada

de forma segura. Inclusive o governo tem contribuído para isso, através da sua infra-

estrutura de chaves publicas regulamentando as atividades de certificação digital no

País.

53
REFERÊNCIAS BIBLIOGRÁFICAS

AMORIM, Simone da Silva. A Tecnologia Web Services e sua Aplicação num

Sistema de Gerência de Telecomunicações. Março, 2007. Dissertação de
Mestrado Profissional(Instituto de Computação) - Universidade Estadual de
Campinas, São Paulo.

AXIS, Web Services - Axis. Disponível em: http://ws.apache.org/axis/. Acesso em:

junho de 2008.
CXF, Apache CXF: An Open Source Service Framework. Disponível em:
http://cxf.apache.org/ Acesso em: junho de 2008.

BIANCHI, Cláudio. Método para Análise, Especificação, Desenvolvimento e

Governança e uma SOA. 2007. Monografia (MBA em Tecnologia da Informação) -
Escola Politécnica da Universidade de São Paulo, São Paulo.

BIEBERSTEIN, N. et al. Service Oriented Architecture (SOA) Compass. NJ, EUA:

IBM, 2006.

BOARO, Marcio. Web Services: Uma visão Inicial. MSDN Brasil. Disponível em:
http://www.microsoft.com/brasil/msdn/colunas/webservices/col_webservices_1.aspx.
Acesso em: novembro 2008.

FELIPE, Pedro. Tecnologias Web. Apache CXF. Abril, 2008. Disponível em:
http://pedrofao.blogspot.com/2008/04/apache-cxf.html. Acesso em: novembro 2008.

GUNZER, Hartwig. Introduction to Web Services, Sales Engineer, Borland. Março,

2002

IDC, Analyze the Future. Worldwide Web Security 2007-2011 Forecast and 2006
Vendor Shares, (Excerpt from IDC #210034). Dezembro, 2007.

ICP-BRASIL, Infra-Estrutura de Chaves Públicas Brasileira. Curso para Agentes de

Registro da ICP-Brasil - versão 2.5. Disponível em :
http://www.iti.gov.br/twiki/bin/view/Certificacao/CursoAgentes. Acesso em: março de
2008.

IBM, Por dentro da SOA. Disponível em : http://www-

01.ibm.com/software/br/info/features/futureenterprise/index.shtml. Acesso em:
dezembro de 2008.

IBM, Web Services Security, 05 Abril 2002. Disponível em : http://www-

128.ibm.com/developerworks/library/specification/ws-secure/. Acesso em: julho de
2008.

JAVA MAGAZINE. Web services com WS-*: Programando um sistema de leilão, com
Axis e WTP. Grajaú: Editora DevMedia, edição 55, ano VII, 2008. 24 p.

54
KREGER, Heather. Ibm Conceptual Architecture (WSCA 1.0). IBM Software Group.
Maio, 2001.

VARCHAVSKY, Márcio. Segurança em Web services com WSS4J. MUNDO

JAVA. Curitiba: Editora Mundo, n.28, a.V, 2008, 34 p.

OASIS. Organization for the Advancement of Structured Information Standards

Comitê de Especificação. Modelo de Referência para Arquitetura Orientada a
Serviço 1.0. Julho, 2006.

ROSENBERG, J. & Remy, D., Securing Web Services with WS-Security:

Demystifying WS-Security, WS-Policy, SAML, XML Signature and XML Encryption.
SAMS, 2004

TOLOMELLI, Leonardo. Web Services: um novo modelo de negócios para Internet.

MSDN Brasil. Disponível
http://www.microsoft.com/brasil/msdn/colunas/batepapo/col_batepapo_3.aspx.
.Acesso em: novembro 2008.

W3C, World Wide Web Consortium, Web Services Activity, Disponível em:
http://www.w3.org/2002/ws/. Acesso em: junho de 2008.

W3C, Extensible Markup Language (XML) 1.0 (Second Edition), W3C

Recommendation, 6 Outrubro 2000. Disponível em:
http://www.w3.org/TR/2000/REC-xml-20001006. Acesso em: junho de 2008.

W3C, Web Services Description Language (WSDL) 1.1, W3C Note, 15 Março 2001.
Disponível em: http://www.w3.org/TR/wsdl. Acesso em: junho de 2008.

W3S, W3Schools, SOAP Tutorial. Disponível em:

http://www.w3schools.com/soap/default.asp. Acesso em: novembro de 2008.

WATHIER, Adair José. Segurança em Web Services com WS-Security.

Dezembro, 2005. Monografia (Especialização em Desenvolvimento, Segurança e
Qualidade na Internet) - Universidade Federal do Rio Grande do Sul, Porto Alegre,
Rio Grande do Sul.

WIKIPEDIA, A Enciclopédia Livre. Apache CXF. Disponível em:

http://en.wikipedia.org/wiki/Apache_CXF. Acesso em: novembro de 2008.

WSS4J, Apache WSS4J. Disponível em: http://ws.apache.org/wss4j. Acesso em:

novembro de 2008.

XYZWS, SCDJWS Certification. Disponível em:

http://www.xyzws.com/scdjws.do?cat=scdjws. Acesso em: novembro de 2008.

55