Baixar este arquivo PDF - Portal de Revistas UNIPLAC

UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE SISTEMAS DE INFORMAÇÃO
(BACHARELADO)
SEGURANÇA EM WEB SERVICES COM JAVA
FERNANDO LUIZ PARISOTTO
LAGES, NOVEMBRO DE 2006.
UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE SISTEMAS DE INFORMAÇÃO
(BACHARELADO)
SEGURANÇA EM WEB SERVICES COM JAVA
Relatório do Trabalho de Conclusão de
Curso submetido à Universidade do
Planalto Catarinense para obtenção dos
créditos da disciplina Trabalho de
Conclusão de Curso do curso de
Sistemas de Informação - Bacharelado.
FERNANDO LUIZ PARISOTTO
Orientador: Prof. Marcos André Pisching,
M.Sc.
LAGES, NOVEMBRO DE 2006.
SEGURANÇA EM WEB SERVICES COM JAVA
FERNANDO LUIZ PARISOTTO
ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI
JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA
DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII
SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM SISTEMAS DE INFORMAÇÃO
Prof. Marcos André Pisching, M.Sc.
Orientador
BANCA EXAMINADORA:
_________________________________ _________________________________
UNIPLAC
UNIPLAC
Prof. Angelo Augusto Frozza, Esp.
Professor de TCC
Prof. Wilson Castello Branco Neto, Dr.
Coordenador de Curso
Lages, 6 de dezembro de 2006.
Dedico este trabalho a minha noiva
Fernanda pelo amor e carinho, aos meus
pais Noelite e Ivo pelo apoio e a meu
amigo e orientador Marcos.
SUMÁRIO
LISTA DE ILUSTRAÇÕES ................................................................................... VIII
LISTA DE SIGLAS ...................................................................................................... X
RESUMO .................................................................................................................... XII
ABSTRACT ............................................................................................................. XIII
1 INTRODUÇÃO................................................................................................................ 1
1.1 Apresentação ............................................................................................................. 1
1.2 Descrição do problema .............................................................................................. 2
1.3 Justificativa ................................................................................................................ 3
1.4 Objetivo geral ............................................................................................................ 4
1.5 Objetivos específicos ................................................................................................. 4
1.6 Metodologia ............................................................................................................... 4
2 WEB SERVICES.............................................................................................................. 6
2.1 O que são Web Services? ........................................................................................... 6
2.2 Arquitetura dos Web Services, padrões e tecnologias ............................................. 10
2.3 Troca de Mensagens XML – SOAP ........................................................................ 11
2.4 Descrição dos Web Services – WSDL ..................................................................... 15
2.5 Publicação e descoberta do Web Service – UDDI ................................................... 19
2.6 Java Web Services ................................................................................................... 22
2.6.1 Java Web Services Developer Pack................................................................................. 23
2.6.2 Java API for XML Web Services ..................................................................................... 24
2.6.3 Java API for XML-Based RPC ........................................................................................ 24
2.6.4 Java API for XML Registries ........................................................................................... 25
2.6.5 Java Architecture for XML Binding ................................................................................ 25
2.6.6 SOAP with Attachments API for Java ............................................................................. 26
2.6.7 XML and Web Services Security ...................................................................................... 26
2.7 Conclusão ................................................................................................................ 26
3 SEGURANÇA EM WEB SERVICES ................................................................................ 28
3.1 Introdução ................................................................................................................ 28
3.2 Visão geral sobre segurança .................................................................................... 29
3.2.1 Identificação e autenticação ............................................................................................ 30
3.2.2 Autorização...................................................................................................................... 31
3.2.3 Integridade ...................................................................................................................... 32
3.2.4 Privacidade...................................................................................................................... 32
3.2.5 Não-repúdio ..................................................................................................................... 33
3.3 Técnicas e tecnologias de segurança ....................................................................... 33
3.3.1 Criptografia ..................................................................................................................... 34
3.3.2 Assinaturas digitais ......................................................................................................... 39
3.3.3 Certificados digitais ........................................................................................................ 41
3.4 Camadas de segurança em Web Services ................................................................ 43
3.4.1 Segurança sobre a camada de transporte ....................................................................... 44
3.4.2 Segurança sobre camada de mensagem .......................................................................... 47
3.5 Conclusão ................................................................................................................ 50
4 ANÁLISE E MODELAGEM DO SISTEMA ...................................................................... 52
4.1 Concepção ............................................................................................................... 52
4.2 Sumário executivo ................................................................................................... 52
4.3 Levantamento de requisitos ..................................................................................... 53
4.4 Lista de consultas .................................................................................................... 55
4.5 Requisitos suplementares ........................................................................................ 56
4.6 Organização de requisitos........................................................................................ 57
4.6.1 Listas de caso de uso ....................................................................................................... 57
4.6.2 Lista de conceitos e operações cadastrais ...................................................................... 57
4.7 Fase de elaboração ................................................................................................... 58
4.8 Fase do projeto......................................................................................................... 60
4.8.1 Descrição do sistema ....................................................................................................... 60
4.8.2 Arquitetura do sistema .................................................................................................... 61
4.8.3 Diagrama de classes........................................................................................................ 62
4.9 Padrões de projeto utilizados ................................................................................... 64
4.9.1 Session Fachade .............................................................................................................. 65
4.10 Conclusão .............................................................................................................. 66
5 DESENVOLVIMENTO E CONFIGURAÇÃO DO SISTEMA. ............................................. 68
5.1 Requisitos de software ............................................................................................. 68
5.2 Instalação e configuração do ambiente.................................................................... 69
5.2.1 Instalação do Java Standard Edition Developer Kit 5 e configuração das variáveis de
ambiente: ........................................................................................................................ 69
5.2.2 Instalação do PostgreSQL 8.1: ....................................................................................... 69
5.2.3 Instalação do eclipse 3.2: ................................................................................................ 69
5.2.4 Instalação do Sun Java System Application Server Platform Edition 9 ......................... 70
5.3 Codificação do sistema ............................................................................................ 71
5.3.1 Camada de domínio ......................................................................................................... 71
5.3.2 Fachada do sistema ......................................................................................................... 80
5.3.3 Camada de persistência................................................................................................... 82
5.4 Implementação da segurança ................................................................................... 91
5.4.1 Arquivo de segurança ...................................................................................................... 91
5.4.2 Codificação dos CallbackHandlers ................................................................................. 95
5.5 Arquivos de configuração do sistema.................................................................... 103
5.5.1 Arquivos do servidor ..................................................................................................... 103
5.5.2 Arquivos do cliente ........................................................................................................ 104
5.6 Desenvolvimento do cliente Web Service ............................................................. 105
5.7 Demonstração do ambiente ................................................................................... 108
5.7.1 Web Service não seguro ................................................................................................ 108
5.7.2 Web service seguro ........................................................................................................ 110
5.8 Conclusão .............................................................................................................. 113
6 CONSIDERAÇÕES FINAIS .......................................................................................... 115
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 118
BIBLIOGRAFIA COMPLEMENTAR ................................................................... 121
APÊNDICE - ARTIGO ............................................................................................. 122
LISTA DE ILUSTRAÇÕES
FIGURA 1 FIGURA 2 FIGURA 3 FIGURA 4 FIGURA 5 FIGURA 6 FIGURA 7 FIGURA 8 FIGURA 9 FIGURA 10 FIGURA 11 FIGURA 12 FIGURA 13 -
Arquitetura dos Web Services. ............................................................ 10
Modelo de fluxo de um processo de requisição a um repositório
UDDI. .................................................................................................. 22
Criptografia simétrica. ......................................................................... 35
Criptografia assimétrica. ..................................................................... 37
Processo de Handshake. ...................................................................... 38
Processo de assinatura digital de um documento. ............................... 41
Processo de comunicação através do protocolo SSL. ......................... 44
Modelo de conceitual .......................................................................... 60
Arquitetura do sistema ........................................................................ 62
Diagrama de classe. ............................................................................. 63
Modelo lógico do banco de dados ....................................................... 64
Diagrama de classe do padrão Session Façade. .................................. 66
Imagem da janela principal do sistema. ............................................ 107
QUADRO 1 - Mensagem SOAP ................................................................................ 12
QUADRO 2 - Código de resposta a uma requisição SOAP com resultado falho. ..... 13
QUADRO 3 - Documento WSDL que apresenta um método sayHello por um Web
Service. ................................................................................................ 18
QUADRO 4 - Cadastro de Clientes ............................................................................ 54
QUADRO 5 - Cadastro de Produtos ........................................................................... 54
QUADRO 6 - Cadastro de Ordem de Compra ........................................................... 55
QUADRO 7 - Cadastro de Categoria ......................................................................... 55
QUADRO 8 - Lista de consultas ................................................................................ 56
QUADRO 9 - Requisitos suplementares .................................................................... 56
QUADRO 10 - Lista de caso de uso ............................................................................. 57
QUADRO 11 - Lista de operações cadastrais .............................................................. 58
QUADRO 12 - Expansão do caso de uso Ordem de Compra ...................................... 59
QUADRO 13 - Classe Endereço. ................................................................................. 73
QUADRO 14 - Implementação da classe Cliente. ....................................................... 75
QUADRO 15 - Implementação da classe Categoria. ................................................... 76
QUADRO 16 - Implementação da classe Produto. ...................................................... 77
QUADRO 17 - Implementação da classe OrdemCompra. ........................................... 78
QUADRO 18 - Implementação da classe ProdutoOrdemCompra. .............................. 79
QUADRO 19 - Interface que representa a Fachada do Cliente. ................................... 81
QUADRO 20 - Interface que representa a Fachada do Administrador. ....................... 81
QUADRO 21 - Arquivo de configuração da JPA, persistence.xml. ............................ 84
QUADRO 22 - Implementação do Web Service Administrador. ................................ 86
QUADRO 23 - Implementação do Web Service Cliente. ............................................ 89
QUADRO 24 - Arquivo de segurança do Web Service Administrador. ...................... 92
QUADRO 25 - Arquivo de segurança do Web Service Cliente................................... 93
QUADRO 26 - Implementação da classe SecurtyCallbackHandler. ........................... 97
QUADRO 27 - Implementação da classe DefaultSecurityHandler. ............................ 98
QUADRO 28 - Implementação da classe AdministradorSecurityHanler. ................. 100
QUADRO 29 - Implementação da classe ClienteSecurityHandler. ........................... 102
QUADRO 30 - Arquivo MANIFEST.MF do projeto Cliente. ................................... 105
QUADRO 31 - Quadro demonostrando a troca de mensagens não seguras. ............. 109
QUADRO 32 - Quadro demonstrando a troca de mensagens seguras. ...................... 110
LISTA DE SIGLAS
API
BSP
B2B
B2C
CA
CORBA
CRL
CRM
C2B
DAO
ERP
FTP
G2B
HTTP
HTTPS
IETF
ICP
IP
JAVA EE
JAXB
JAXR
JAX-RPC
JAX-WS
JAX-WSA
JWSDP
MIME
OASIS
OSI
PKI
PU
RCP
RDF
- Application Programming Interface
- Basic Security Profile
- Business to Business
- Business to Customer
- Certificate Authorities
- Common Object Request Broker Architeture
- Certificate Revocation List
- Customer Relationship Management
- Customer to Business
- Data Access Object
- Enterprise Resource Planning
- File Transfer Protocol
- Government to Business
- Hypertext Transfer Protocol
- HyperText Transfer Protocol Secure
- Internet Engineering Task Force
- Infraestrutura de Chave Pública
- Internet Protocol
- Java Enterprise Edition
- Java Architecture for XML Binding
- Java API for XML Registries
- Java API for XML-Based RPC
- Java API for XML Web Services
- Java API for XML Web Services Addressing
- Java Web Services Developer Pack
- Multipurpose Internet Mail Extensions
- Organization for the Advancement of Structured Information
Standards
- Open Systems Interconnection
- Public Key Infrastructure
- Processo Unificado
- Remote Procedure Call
- Resource Description Framework
REL
RMI
SAAJ
SAML
SMTP
SOAP
SSL
TCP
UDDI
UML
URL
WSDL
WS-I
W3C
XACML
XML
XWSS
- Rights Expression Language
- Remote Method Invocation
- SOAP with Attachments API for Java
- Security Assertion Markup Language
- Simple Mail Transfer Protocol
- Simple Object Access Protocol
- Secure Sockets Layer
- Transmission Control Protocol
- Universal Description, Discovery and Integration
- Unified Modeling Language
- Universal Resource Locator
- Web Services Description Language
- Web Services Interoperability
- World Wide Web Consortium
- eXtensible Access Control Markup Language
- eXtensible Markup Language
- XML Web Services Security
RESUMO
Web Services é a nova tendência para sistemas distribuídos que operam na Internet,
possibilitando uma arquitetura orientada a serviços, baixamente acoplada. Porém, para
a adoção desta tecnologia em ambientes corporativos, nos quais dados confidenciais
transitam em um cenário de e-commerce, é necessário garantir segurança, através de
confidencialidade nos dados trocados, autenticação das partes interessada e integridade
dos dados a serem transmitidos. De acordo com essas necessidades, este trabalho
apresenta um estudo sobre como garantir e oferecer a segurança em um sistema que
faz uso da tecnologia Web Services. O trabalho tem como objetivo principal apresentar
os principais conceitos da implementação de segurança em Web Services, e as
principais tecnologias envolvidas nesse processo, focando principalmente na
segurança sobre a camada de mensagem. Para isso, é demonstrado através de um
estudo de caso, um ambiente seguro com as tecnologias aplicadas, no qual é possível
distinguir a diferença entre uma transação com segurança em Web Services, e uma sem
segurança.
Palavras-chave: Web Services; Segurança; Java.
ABSTRACT
Web Services is the new trend for distributed systems that operate in the Internet, making
possible service oriented architecture, loosely coupled. However, for the adoption of this
technology in the corporative environment, where confidential data are transit in a scene of ecommerce, it is necessary to guarantee security, through confidentiality in exchanged data,
authentication of the interested parts and integrity of the data transmitted. In a accordance
with these needs, this work presents a study about how to guarantee and to offer the security
in a system that makes use of the Web Services technology. The work has a main objective to
present the main concepts in implementation of security in Web Services, and the main
involved technologies in this process, focus in message level security. For this, is
demonstrated, in a study of case, a secured environment with the applied technologies, where
it is possible to distinguish the difference enters a transaction with a safe Web Services to a
not safe.
Keywords: Web Services; Security; Java.
1 INTRODUÇÃO
1.1 Apresentação
Na época do surgimento da Internet, pouco se falava em negócios on-line,
pois era voltada mais para o ambiente acadêmico, pesquisas e troca de informações
entre instituições de ensino. Muitas das tecnologias conhecidas e utilizadas atualmente
não tinham sido elaboradas ou, então, eram apenas teorias.
Porém, nos últimos anos, nota-se que houve uma grande expansão no
comércio na Internet, com um movimento iniciado por empresas que decidiram
estender sua disponibilidade ao cliente para o mundo virtual, usando as vantagens que
a rede mundial de computadores oferece, como a disponibilidade de vinte e quatro
horas por dia e sete dias por semana e a comercialização global. Com isso, termos
como e-Business e e-Commerce surgiram no cotidiano das corporações comerciais.
A Internet é a maior rede de computadores do mundo, na qual vários
sistemas de várias plataformas operam conectados. Tendo em vista isso, as
corporações comerciais decidiram fazer uso dessa tecnologia para expandir suas
capacidades de negócio. Porém, para realizar este feito, estas precisam de tecnologias
que permitam que seus sistemas possam se conectar de modo transparente a este
ambiente e oferecer seus recursos para entidades interessadas.
Surge, então, à proposta da tecnologia de Web Services, que visa sanar essa
necessidade de integração de sistemas em um ambiente heterogêneo e distribuído. Web
Services são independentes de plataforma, linguagens de desenvolvimento e de
sistema operacional. Seu principal intuito é de integrar sistemas distintos, utilizando-se
dos padrões e protocolos de comunicação já existentes e operacionais na Internet.
A tecnologia de Web Services é uma ótima solução para integração de
sistemas coorporativos. Porém, quando se trata de sistemas que transportam
informações confidenciais que põem em risco as empresas se estas estiverem expostas,
cria-se a necessidade de utilizar metodologias e políticas de segurança para garantir
certo nível de confiabilidade nas transações realizadas por esses sistemas.
Este trabalho objetiva proporcionar um embasamento teórico das tecnologias
envolvidas no desenvolvimento de Web Services que utilizem metodologias de
segurança. Também visa exemplificar a implementação das tecnologias abordadas
aplicadas a um estudo de caso, tornando-o, assim, um guia prático para o
desenvolvimento de um sistema similar.
O presente trabalho está estruturado da seguinte forma: além deste capítulo
introdutório; o capítulo 2 apresenta um levantamento teórico sobre a tecnologia de
Web Services e sua integração com a plataforma Java; no capítulo 3 são apresentados
todos os conceitos e recursos relevantes para aplicação de segurança em Web Services;
no capítulo 4 é explorado o desenvolvimento do estudo de caso abordado pelo
trabalho, sua modelagem, arquitetura e implementação; no capítulo 5 é vista a
implementação do cliente do Web Service desenvolvido no capítulo anterior. Também
é abordada a sua modelagem e implementação. Após isso, são apresentados os
resultados obtidos por essa experiência. Por fim, no capítulo 6, são feitas as
considerações finais deste trabalho e recomendações para trabalhos futuros.
1.2 Descrição do problema
O uso da tecnologia de Web Services visa a integração de sistemas em um
ambiente heterogêneo de plataformas e arquiteturas. Porém, um dos principais
obstáculos para a adoção efetiva desta tecnologia é a segurança, pois Web Services
provêm uma interface do ambiente interno ao ambiente externo que possibilita às
entidades realizar operações que potencialmente podem expôr informações cruciais da
empresa e sua privacidade, tornando vulnerável à ataques a dados. Assim sendo, uma
grande preocupação no uso de Web Service é como garantir e oferecer um determinado
nível de segurança de acordo com o tipo de informação que é transmitida pela rede.
1.3 Justificativa
Atualmente, o mundo dos negócios vem confiando cada vez mais na Internet
como sendo o principal meio de transporte para comunicações e transações comerciais.
Para que estas comunicações aconteçam, é necessário construir aplicações cada vez
mais seguras e que atendam às necessidades deste tipo de ambiente distribuído.
Uma aplicação segura deve manter mecanismos que garantam a segurança
dos dados por ela manipulados. Como Web Services são sistemas que atuam na
Internet, que por sua vez é um ambiente heterogêneo e oferece altos riscos de
segurança, deve-se enfatizar o uso de técnicas que garantem a confiabilidade das
transações efetuadas por esses sistemas.
Vale ressaltar que: “Uma das grandes vantagens do SOAP é que, ao usar a
porta 80 do HTTP, você pode enviar requisições diretamente através de firewall!
Entretanto, uma das grandes desvantagens do SOAP é que ao usar a porta 80 do
HTTP, você pode enviar requisições diretamente através do firewall!” (HENDRICKS
et al., 2002).
Com esta afirmação, HENDRICKS et al. (2002) enfatiza que uma das
principais vantagens desta arquitetura de sistemas distribuídos é a total
interoperabilidade do sistema no ambiente Web. Em contra partida, isso se torna um
ponto crítico na confiabilidade do sistema devido ao nível de exposição ao meio
externo, pois não há outros mecanismos que ofereçam segurança além do firewall (o
protocolo SOAP é abordado no capítulo 3 sobre Web Services, no qual dará maior
sentido para esta afirmação).
Segundo Eve Maler (SUN MICROSYSTEMS, 2005), presidente do Security
Work Plan Working Group of WS-I (Web Services Interoperability Organization), em
uma entrevista a equipe da Sun Developer Network, ela afirma que o que mais falta
agora é um modo padrão de negociar os obstáculos de segurança que os serviços de
requisições e respostas irão aderir.
Devido a esse tipo de necessidade, justifica-se o estudo realizado por este
trabalho, pois as organizações que farão uso desse tipo de tecnologia precisam de um
sistema que atue em um ambiente seguro.
1.4 Objetivo geral
O objetivo geral deste trabalho é apresentar os principais recursos utilizados
para definir métodos e políticas de segurança em Web Services aplicados a um estudo
de caso.
1.5 Objetivos específicos
a) Apresentar os principais padrões envolvidos na especificação de Web Services;
b) Levantar os principais recursos para aplicação de segurança em Web Services;
c) Desenvolver um Web Service utilizando os recursos de segurança apresentados
pelo estudo realizado;
d) Demostrar a interação dos clientes com o serviço implementado num ambiente
seguro.
1.6 Metodologia
O estudo começa com um levantamento bibliográfico e reconhecimento do
tema a ser abordado.
Foi produzido o projeto do Trabalho de Conclusão de Curso, pelo qual foi
introduzido o conhecimento superficial sobre Web Services, Internet para negócios e
segurança. Também foi apresentado o problema que o trabalho tratou, seu objetivo e a
justificativa da realização do mesmo.
O próximo passo trata de em abordar a tecnologia de Web Service e sua
utilidade no ambiente coorporativo. É ser especificados os conceitos da tecnologia,
seus padrões e protocolos. Após a conclusão do levantamento teórico, serão
apresentados os recursos que a plataforma Java oferece para o desenvolvimento de
Web Services.
Em seguida, foram apresentadas as metodologias e políticas de segurança na
utilização de Web Services. Para tal, foi feita uma breve introdução da tecnologia e
apresentados os conceitos de segurança relevantes para aplicações que utilizem Web
Services. Depois, são abordados os recursos disponíveis para o desenvolvimento de
Web Services que implementem os requisitos de segurança anteriormente definidos.
Foi desenvolvido um estudo de caso voltado à indústria madeireira do
Planalto Catarinense, que aborda todo o conteúdo teórico levantado até o momento.
Após isso é apresentado a modelagem do sistema e sua arquitetura.
Com a conclusão da modelagem, foi iniciada a implementação do sistema,
que consiste em implementar os Web Services e seus clientes, todos aplicados em um
ambiente seguro.
Finalizada
a
implementação,
foram
apresentados
os
resultados
e
considerações finais e, também, a demonstração do sistema atuando no ambiente
seguro.
2 WEB SERVICES
Este capítulo apresenta uma introdução aos principais conceitos da
tecnologia Web Service, sua arquitetura, pilha de protocolos envolvidos. Após, são
abordadas as três principais camadas dos Web Services: mensagens, descrição e
descoberta. E, finalmente, são introduzidas as principais tecnologias Java para
construção de aplicações Web Services.
2.1 O que são Web Services?
O conceito principal de Web Services é simples, consiste em Chamadas de
Procedimento Remoto ou, como é mais comumente conhecido, RPC (Remote
Procedure Calls). Web Service não é a primeira tecnologia a implementar essa
funcionalidade (CORBA e Java/RMI (Remote Method Invocation) também provêem
RPC), porém é diferente das tecnologias já existentes.
Web Service é independente de linguagem de programação e sistema
operacional por usar padrões abertos e consolidados tais como HTTP (HyperText
Transfer Protocol) e XML (eXtensible Markup Language), com isso o desenvolvedor
não precisa saber se o serviço foi implementado em Java ou se será acessado pela
plataforma .NET da Microsoft, porém, diferente de CORBA, que necessita de portas e
protocolos especificos para operar, Web Services opera no protocolo HTTP da rede
TCP/IP o que o torna mais adaptavel para Internet.
Em 1999, a Hewlett-Packard tornou-se a primeira empresa de software a
introduzir o conceito de Web Services. A HP introduziu o produto e-Speak, uma
plataforma que possibilitava aos desenvolvedores produzir e programar os e-services,
programas similares a Web Services. Entretanto a natureza proprietária do e-Speak o
impossibilitou de ganhar espaço e simpatia da indústria de software.
Foi a Microsoft quem cunhou o termo Web Services em junho de 2000,
quando a mesma introduzia os Web Services como componentes chave de sua
plataforma .NET, com intuito de abraçar a Internet para o desenvolvimento,
engenharia e usabilidade do software. A Microsoft anunciou que estava apostando
todas as suas fixas nessa tecnologia, em seguida os Web Services tornou-se a grande
novidade (DEITEL et al. 2003).
Os principais objetivos da tecnologia Web Services são (DEITEL et al.
2003):
 Solucionar o problema da interoperabilidade através do uso de uma plataforma
neutra e remover o antagonismo existente;
 Criar uma camada de abstração entre nodos heterogêneos em uma rede;
 Ser extremamente acessível por todas as plataformas através do uso de protocolos
da Internet e XML, isto é, permitir que um sistema desenvolvido em Java rodando
em uma plataforma Solaris se comunique com um sistema .NET operando em
plataforma Windows;
 Permitir a interoperabilidade entre quaisquer tipos de sistemas, não somente entre
sistemas ERP (Enterprise Resource Planning), sistemas CRM (Customer
Relationship Management) e base de dados relacionais;
 Prover solução de sobre passo em firewalls, assim permitindo que qualquer cliente
consiga acessar o serviço;
 Tirar proveito da redução na comunicação e nos custos dos servidores que não
possuíam um bom custo/benefício anos atrás;
 Argumentar em prol do desenvolvimento de sistemas como um conjunto de
serviços distribuídos e não como um componente que é executado dentro de um
único processo.
O W3C Web Service Architecture Working Group (W3C, 2006a), que é o
grupo responsável pelo desenvolvimento de novas especificações para tecnologia Web
Services estabeleceu a seguinte definição para serviços Web:
Um Web Services é um software designado a suportar interoperabilidade e integração entre
máquina-a-máquina por uma rede. Através de uma interface descrita da máquina
(especificação WSDL). Outros sistemas interagem com o Web Services pela interface de
descrição usando mensagens SOAP, usando HTTP com serialização de XML em um
conjunto de outros padrões Web (W3C, 2006a).
Porém, uma definição mais simples pode ser útil para a compreensão da
tecnologia: um Web Service é uma aplicação acessível pela Web (ou em uma Intranet)
por um endereço (URL) e que pode ser acessado por clientes usando protocolos
baseados em XML (como SOAP), enviados através de protocolos da Internet já
consolidados (como o HTTP). Os clientes acessam este serviço através de interfaces
de mapeamento e especificação disponibilizadas pelo serviço (como o WSDL).
Web Services é um agrupamento de tecnologias padronizadas que, reunidas,
representam o seu comportamento e funcionalidade. O uso desses meios é que obtém
uma tecnologia que proporciona completa interoperabilidade entre plataformas e
sistemas distintos. Essa tecnologia foi desenvolvida com a base de conhecimento já
obtido por CORBA, Java/RMI, habilitando a comunicação e interoperabilidade entre
aplicações, provendo um meio padronizado de aplicações expor suas funcionalidades
na Web e de comunicar entre outros sistemas.
Web Services oferece uma série de vantagens como tecnologia, o que a torna
segura para o investimento, devido o amplo suporte da comunidade desenvolvedora e
certa garantia de continuidade da tecnologia. As principais vantagens dos Web
Services são (DEITEL et al. 2003):
 Interoperabilidade em um ambiente heterogêneo – permitir que os serviços
rodem em diferentes tipos de plataformas e arquiteturas, que o software seja
escrito em diferentes tipos de linguagens de programação, e que sistemas
diferentes facilmente se comuniquem e interajam uns com os outros;
 Disponibilização dos serviços para a rede (Internet ou Intranet) – a
aplicação pode fazer uso das vantagens da utilização da Web para a sua
operação, dando para a empresa uma vantagem comercial no seu negócio,
disponibilizando seus serviços para os clientes;
 Integração entre sistemas já existentes – a maioria das empresas têm dados
armazenados em seus sistemas legados e para elas não é uma opção viável
abandonar essas informações armazenadas durante a sua existência
comercial em troca de uma atualização na sua plataforma. Web Services
permitem que essas informações legadas possam ser usadas com
transparência
em
novos
sistemas
desenvolvidos.
Web
Services
disponibilizam para os desenvolvedores um meio padronizado para acessar
sistemas legados como bancos de dados e sistemas antigos e os integrá-los
com novas aplicações, com isso não há a necessidade de aprendizado de
novas tecnologias para a expansão do sistema;
 Liberdade de escolha – Web Services é de um padrão aberto e com um
grande suporte por empresas de desenvolvimento e comunidades, que
provêem ferramentas, produtos e tecnologias para o desenvolvimento. Isso
fornece uma ampla variedade de escolha, que dá a possibilidade de escolher
melhor o ambiente conforme os requisitos do sistema a ser desenvolvido;
 Suporte a mais clientes – não importa se os clientes usam Java ou a
plataforma .NET da Microsoft, todos podem fazer uso de Web Services.
Aumenta o conjunto de possíveis clientes da aplicação, criando novas
oportunidades de negócio.
 Produtividade – aplicações devem ser desenvolvidas rapidamente, devem
passar de protótipos para sistemas de produção e, mesmo após a sua entrega
devem continuar evoluindo. Web Services eliminam vários contratempos na
produção de software distribuídos e na integração entre ambientes legados.
Tornando assim mais fácil para a equipe de desenvolvimento se concentrar
na resolução do problema do cliente ao invés de aprender outras linguagens
de programação para integrar o sistema ou então migrar os sistemas já
existentes em produção para a nova plataforma imposta.
2.2 Arquitetura dos Web Services, padrões e tecnologias
Web Services é um conjunto de tecnologias integradas, esta seção visa
esclarecer o modelo desta tecnologia, suas partes e como estas funcionam juntas. Para
melhor compreensão da tecnologia, a Figura 1 mostra modelo conceitual dos Web
Services:
FIGURA 1 - Arquitetura dos Web Services.
(HENDRIKCS et al., 2002)
O modelo destaca três entidades e suas operações (HENDRICKS et al.,
2002):
 Provedor de serviços – é o servidor do serviço, é quem o disponibiliza na
Web. Tem a obrigação de descrever o serviço por ele disponibilizado de
forma padronizada, que seja compreensível por qualquer outra entidade
interessada na sua utilização. Após isso pronto o provedor precisa publicar
os detalhes de seu serviço em um registro central que está disponível para
todas as entidades que possivelmente irão o acessá-lo;
 Consumidor de serviço – é quem usa o Web Service, o cliente do serviço. O
consumidor pode obter as informações do serviço a ele interessado através
de uma pesquisa no registro onde o serviço está publicado. Neste, também é
possível obter informações de vínculo do serviço, isto é, o seu exato
endereço na Web para poder acessá-lo;
 Registro dos serviços – é o local onde os provedores de serviços publicam
informações sobre seus serviços, conseqüentemente, é também o local onde
os consumidores de serviços buscam informações sobre os serviços a eles
interessados. Tipicamente, informações como detalhes da empresa, Web
Services por ela fornecidos e detalhes sobre cada serviço Web, inclusive
detalhes técnicos, são armazenadas no registro do serviço. O registro de
serviços fornece duas funcionalidades aos seus clientes, uma para pesquisa
de serviços nele contido e outra para postagem de um novo serviço em seu
repositório.
2.3 Troca de Mensagens XML – SOAP
Segundo a recomendação W3C (2006a), SOAP 1.2, é um protocolo que visa
à troca de informações em um ambiente descentralizado e distribuído. Usa a
tecnologia XML para definir um framework de troca de mensagens extensível onde se
pode construir e trocar mensagens sobre uma variedade de protocolos. Este framework
foi desenvolvido para ser independente de qualquer modelo de programação ou
semântica (W3C, 2006a).
SOAP (Simple Object Access Protocol) fornece a objetos desconhecidos um
meio de se comunicarem através de troca de mensagens. SOAP é um protocolo
baseado em texto que usa a tecnologia XML para codificar mensagens e transmiti-las
através da Web (HTTP, FTP, SMTP e outros). SOAP é independente de linguagem de
programação e de plataforma e não requisita nenhuma tecnologia para seu
funcionamento.
Antes da existência da tecnologia Web Services aplicações comunicavam-se
através de outras tecnologias de objetos distribuídos, como CORBA. Utilizar essas
tecnologias de RPC na Internet representa um problema de segurança. Firewalls e
proxys bloqueiam este tipo de fluxo na rede, trancando as suas portas de comunicação,
tornando impossível a operação. A melhor solução para este problema era usar um
protocolo que não fosse interferido por firewalls, como o HTTP ou o SMTP (Simple
Mail Transfer Protocol), que são suportados por todas as redes.
Uma mensagem SOAP é codificada em um documento XML, a sua sintaxe é
simples e contém as seguintes partes (HENDRICKS et a., 2002):
 SOAP Envelope: é o envelope principal, define o conteúdo da mensagem e
os vários namespaces que são usados pelo resto da mensagem, incluindo
xmlns:SOAP-ENV (SOAP Evelope) visto linha 6 do Quadro 1.
 SOAP Header (opcional): é o cabeçalho da mensagem, contém informação a
respeito de autenticação, transação e contabilização, visto na linha 7 do
Quadro 1.
 SOAP Body: é o corpo da mensagem, contém informação a respeito de
métodos e parâmetros a serem chamados ou respostas enviadas. Quando
SOAP é utilizado como RPC, esta parte possui um único elemento que
contém o nome do método, parâmetros e a identificação do serviço,
representado na linha 12 do Quadro 1.
O código do Quadro 1 apresenta uma requisição SOAP a um método de um
Web Service utilizando o protocolo HTTP.
QUADRO 1 - Mensagem SOAP
1
2
3
4
5
6
7
8
9
10
11
12
POST /soap/servlet/rpcrouter HTTP/1.0
Host: localhost:8070
Content-Type: text/xml
Content-Length: 461
SOAPAction: ""
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
</n:alertcontrol>
</env:Header>
13
14
15
16
17
18
<env:Body>
<m:alert env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://example.org/alert">
<m:msg>Fazer compras para o almoço.</m:msg>
</m:alert>
</env:Body>
19
</env:Envelope>
O Quadro 1 mostra o exemplo de como uma mensagem SOAP é codificada
em XML e, também, alguns elementos e atributos fundamentais em um documento
SOAP. Todas as mensagens SOAP devem ter um elemento Envelope que deve ter
definido dois namespace, um para o envelope SOAP (xmlns:SOAP-ENV linha 6) e
outro para indicar o estilo de codificação (SOAP-ENV:encodingStyle linha 14). Uma
mensagem SOAP sem essas duas definições é considerada inválida. O atributo
encodingStyle é o que define as regras de serialização da mensagem SOAP, regras
essas que dizem como a mensagem deve ser transformada em bits e enviada para rede.
O elemento opcional Header (cabeçalho, linha 7) se for usado, deve de ser o
primeiro filho após o elemento Envelope. O elemento Header provê um meio
adicionar atributos como autenticação e transação a uma mensagem SOAP, também se
pode definir como essa mensagem deverá ser tratada.
O elemento Body (corpo, linha 13) que deve estar presente em todas as
mensagens SOAP, deve ser inserido logo após o elemento Header, se este existir. Este
elemento contém as informações da atual requisição, como a chamada dos métodos e é
também neste elemento que serão enviados os dados de resposta da requisição. O
elemento Fault (erro, na linha 3 do Quadro 2) do elemento Body (linha 2 do Quadro 2)
provê um mecanismo de tratamento de erro nas requisições do serviço.
QUADRO 2 - Código de resposta a uma requisição SOAP com resultado falho.
1
2
3
4
5
6
7
8
9
10
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns0="urn:HelloService"
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>
JAXRPCTIE01: caught exception while handling
request: unrecognized operation: sayHello
</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
SOAP é um protocolo que troca mensagens em apenas um sentido, isto é, as
mensagens que são transmitidas não são requisições que necessitam de resposta, são
apenas mensagens que contém dados a serem enviados a um fim. Entretanto, o SOAP
possibilita a construção de padrões de interações complexos, como por exemplo,
requisição/resposta ou requisição/múltiplas-respostas.
SOAP oferece ao desenvolvedor uma série de características que facilitam a
fase de desenvolvimento de um Web Service (HENDRICKS et. al., 2002):
 Framework para troca de mensagens - Utilizando XML é possível a
construção de um framework padrão para troca de mensagens SOAP entre o
consumidor e o provedor, que facilita o desenvolvimento abstraindo a
manipulação complexa de documentos XML;
 Protocolos de transporte - SOAP é um padrão que independe do tipo de
protocolo de transporte. Ele pode ser transportado por diferentes tipos de
protocolos de mais baixo nível, como por exemplo, SMTP, FTP e o mais
utilizado HTTP;
 Múltiplos padrões de mensagens - Apesar das mensagens SOAP serem de
um único sentido é possível combiná-las de modo a criar diversos padrões
de interação. Por exemplo, é possível combinar dois tipos de mensagens de
tal forma que elas atuem como um de requisição e resposta. Além disso,
SOAP pode ser utilizado para a transmissão de documentos XML, e também
na transmissão de anexos através de mensagens SOAP com especificações
de anexos. Esse último modelo de transmissão de dados, denominado de
pacote da mensagem SOAP pela especificação, utiliza o MIME
(Multipurpose Internet Mail Extensions) para descrever como o pacote da
mensagem SOAP será construído;
 Regras para codificação de dados - SOAP utiliza XML Schemas para definir
tipos de dados simples e compostos para todos os elementos dentro da
mensagem SOAP. Através de XML Schemas podem-se converter os tipos
de uma linguagem de programação local para um tipo especificado no XML
Schema;
 Roteamento de mensagens e processamento intermediário - Essa capacidade
existe em virtude de existir dentro da mensagem SOAP partes especiais
(headers) em que se podem inserir pré-requisitos para a mensagem e
questão seja processada por um nodo. Sendo assim, caso a mensagem
chegue a um nodo SOAP que não possui os requisitos definidos na
mensagem ela não será processada. Quando uma mensagem com essa
especificação não é executada no nodo com as devidas características elas
são encaminhadas para intermediários que atendam esses requisitos, estes
são responsáveis por processar blocos especiais do cabeçalho que são
invocados antes do processamento da mensagem principal. Além disso,
podem ser ligados a outros intermediários para criar um workflow;
2.4 Descrição dos Web Services – WSDL
Segundo o grupo do Working Draft da WSDL, a linguagem de descrição de
Web Services (WSDL) provê um modelo em formato XML para descrever um Web
Service. WSDL habilita a separação da descrição da funcionalidade do serviço,
oferecendo detalhes concretos do serviço, “como acessá-lo” e “onde acessá-lo” (W3C,
2006b).
O WSDL descreve três componentes básicos dos serviços
Web
(MARQUEZAN, 2004):
 Tipos de dados – a WSDL tem a capacidade de abstrair os tipos de dados
usados pelo Web Service através de XML Schemas definidos pelo
desenvolvedor, com esta flexibilidade é possível especificar os tipos de
dados manipulados pelo Web Service conforme a necessidade e modelagem
da aplicação;
 Operações – cada operação descrita no documento WSDL oferece uma
interface ao método disponibilizado pelo Web Service. Nesta descrição são
especificados os parâmetros de entrada e saída e seus tipos de dados;
 Protocolo de ligação – no documento WSDL também é descrito os
protocolos inferiores utilizados pelo Web Service (transporte e mensagem).
WSDL não ignora os protocolos que estão abaixo dele, nem considera que
somente um tipo de tecnologia é utilizado nessas camadas inferiores. Ele
permite que esses protocolos sejam especificados. Essa flexibilidade do
WSDL permite que desenvolvedores ou outro software que esteja utilizando
as descrições WSDL possam prover diferentes protocolos de ligação
concretos para as operações definidas em WSDL;
O documento WSDL é composto de definições para descrever um serviço,
existem dois tipos de definições: as concretas e as abstratas (MARQUEZAN, 2004):
 Definições concretas – são constituídas por elementos especificam como é
feito acesso ao serviço através da rede, ou seja, definem uma URL, o tipo de
protocolo usado na camada de mensagem (por exemplo, SOAP ou XMLRPC) e o protocolo da camada de transporte (por exemplo, HTTP ou
SMTP). A definição concreta é composta pelos seguintes elementos:
 Serviços (service, linha 42 do Quadro 3) - são elementos que
constituem uma coleção de portas que especificam os terminais para
um serviço (por exemplo, um listener SOAP), existirá somente uma
definição de serviço em um serviço Web, embora seja possível a
existência de mais de uma definição em um documento WSDL;
 Portas (port, linha 43 do Quadro 3) - elemento que especifica o
endereço de um terminal e o elemento de ligação para ser usado com
o endereço. Cada porta possui um tipo de porta associada e uma
descrição abstrata dessa porta. É importante ressaltar que o conceito
de porta utilizado em WSDL não é o mesmo conceito utilizado em
TCP/IP;
 Ligação (binding, linha 30 do Quadro 3) – é o elemento específico de
um protocolo de transporte e o formato dos dados para as operações, e
mensagens abstratas definidas para um tipo de porta abstrata.
 Definições abstratas - estão relacionadas com os elementos que compreendem a
descrição lógica de um serviço, proporcionando a descrição completa dos métodos
e parâmetros associados a esse serviço. A definição abstrata é composta pelos
seguintes elementos:
 Tipos de portas (portType, linha 24 do Quadro 3) - elemento constitui
uma coleção de operações que compõem o serviço Web, atuando
como se fosse uma API para esse serviço;
 Mensagens (message, linha 18 e 21 do Quadro 3) - elemento é
responsável por agrupar os parâmetros de um método. Ele descreve
uma mensagem, mesmo que essa mensagem seja uma requisição ou
uma resposta;
 Partes (part, linha 19 e 22 do Quadro 3) - elemento provê os detalhes
da definição abstrata de mensagem. Ele define o tipo de dado de cada
"parte” da mensagem, utilizando para isso os tipos de dados
pertencentes esquemas pré-definidos (esquemas padrão do XML,
WSDL tipos, tipos de ligação SOAP, HTTP ou MIME) ou então os
definidos pelos usuários e especificados dentro do documento WSDL;
 Tipos (type, linha 4 do Quadro 3) - elemento descreve todos os tipos
de dados utilizados no documento WSDL. Se o serviço que está sendo
descrito utiliza somente esquemas XML baseados em tipos de dados
simples, como por exemplo, strings ou inteiros, o elemento type não
é necessário.
A definição operação, é a definição responsável por fazer a ligação entre os
grupos de definição abstratas e concretas. As operações fazem o mapeamento entre
essas definições. Sob a perspectiva abstrata, o elemento operation define os métodos
de um Web Service, isso representa que para cada método definido há uma operação
associada. Pelo ponto de vista da definição concreta as operações definem as camadas
de transporte e de mensagem utilizadas pelo Web Service.
As operações também definem o comportamento de cada método de um
serviço Web, abaixo são apresentados os quatro padrões de operações especificados
em WSDL (MARQUEZAN, 2004).
 One-way: o serviço recebe a mensagem. Dessa forma, a operação define um
único elemento de entrada.
 Requisição/Resposta: o serviço recebe uma mensagem e envia uma
mensagem correlacionada. Essa operação possui um elemento de entrada,
seguida de um elemento de saída.
 Solicitação/Resposta: o serviço envia uma mensagem e recebe uma
mensagem correlacionada. Essa operação possui um elemento de saída,
seguida de um elemento de entrada.
 Notificação: o serviço envia uma mensagem. A operação define um único
elemento de saída.
QUADRO 3 - Documento WSDL que apresenta um método sayHello por um Web Service.
1
<?xml version="1.0" encoding="UTF-8"?>
2
3
<definitions name="NewWebService"
targetNamespace="urn:NewWebService/wsdl"
xmlns:tns="urn:NewWebService/wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns2="urn:NewWebService/types"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
4
5
6
7
8
<types>
<schema targetNamespace="urn:NewWebService/types"
xmlns:tns="urn:NewWebService/types"
xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="sayHello">
<sequence/>
</complexType>
9
10
11
12
13
14
15
16
17
<complexType name="sayHelloResponse">
<sequence>
<element name="result" type="string" nillable="true"/>
</sequence>
</complexType>
<element name="sayHello" type="tns:sayHello"/>
<element name="sayHelloResponse" type="tns:sayHelloResponse"/>
</schema>
</types>
18
19
20
<message name="NewWebServiceSEI_sayHello">
<part name="parameters" element="ns2:sayHello"/>
</message>
21
22
23
<message name="NewWebServiceSEI_sayHelloResponse">
<part name="result" element="ns2:sayHelloResponse"/>
</message>
24
<portType name="NewWebServiceSEI">
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<operation name="sayHello">
<input message="tns:NewWebServiceSEI_sayHello"/>
<output message="tns:NewWebServiceSEI_sayHelloResponse"/>
</operation>
</portType>
<binding name="NewWebServiceSEIBinding" type="tns:NewWebServiceSEI">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<operation name="sayHello">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
44
45
46
<service name="NewWebService">
<port name="NewWebServiceSEIPort"
binding="tns:NewWebServiceSEIBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port>
</service>
47
</definitions>
2.5 Publicação e descoberta do Web Service – UDDI
O protocolo UDDI (Universal Description, Discovery and Integration), é um
dos blocos essenciais para o sucesso dos Web Services. UDDI cria um padrão de
interoperabilidade entre as aplicações, que as habilita rapidamente a achar e usar Web
Services disponíveis na Internet. Também disponibiliza registros operacionais para
serem mantidos para diferentes propósitos e contextos. UDDI é um esforço dirigido
pelas principais indústrias de software e, também, por empresas de e-business
liderados pelo consórcio OASIS (UDDI, 2006).
O UDDI é um repositório de registros baseados na Web que fornecem
informações a respeito de uma organização ou entidade que publicou seu serviço Web.
Estes registros são executados em múltiplos servidores (operadores) e podem ser
usados por qualquer um que queira tornar disponíveis informações a respeito de
negócios ou entidades, ou ainda, por qualquer um que queira buscar estas informações.
A informação contida em um documento WSDL é complementar a
informação contida em um registro UDDI. UDDI não armazena ou suporta um
documento WSDL, ele descreve o serviço de forma diferente. Quatro tipos de dados
podem ser encontrados em um registro UDDI (BECKER, CLARO e SOBRAL, 2003):
 businessService: fornece informações sobre uma organização e pode conter
um ou mais businessService;
 businessEntity: fornece informações técnicas e descrições de serviço, que
pode conter um ou mais bindingTemplate;
 bindingTemplate: contém uma referência a um ou mais tModels;
 tModel: utilizado para definições de especificações técnicas de serviço.
A informação fornecida por um registro UDDI pode ser comparada à uma
lista telefônica. As páginas brancas (white pages), fornecem informações tais como
nome da organização, contato e identificadores. As páginas amarelas (yellow pages)
são compostas por um índice de serviços e produtos e as páginas verdes (green pages)
contém informações a respeito de transações, descrições de serviço e invocação de
aplicações (BECKER, CLARO e SOBRAL, 2003).
A UDDI é uma especificação em constante evolução e desenvolvimento, este
processo é coordenado pela UDDI.ORG que é uma organização composta por
empresas como Microsoft, IBM, Ariba, Sun, Oracle e HP. Esta especificação fornece
uma API para consulta e publicação de serviços em registros UDDI. A consulta e
publicação em registros UDDI é executada utilizando-se mensagens no formato
SOAP. Estas operações são baseadas na especificação de uma API proposta por
UDDI.ORG e possuem mensagens específicas para a busca, publicação e alteração de
registros (HENDRICKS et al., 2002).
As principais vantagens da proposta UDDI são, universabilidade, descrição,
descoberta, integração (DEITEL et al., 2003):
 Universalidade – UDDI utiliza da mesma tecnologia XML como SOAP e
WSDL, tornando-o assim universal e legível para qualquer plataforma que
entenda essa tecnologia. UDDI é um serviço que permite que provedores e
consumidores se comuniquem e troquem informações sobre serviços a
serem disponibilizados ou então utilizados. Uma requisição ao registro
UDDI é efetuada pelo seu cliente (provedor ou consumidor) e em seguida
uma resposta à requisição é enviada, essa resposta é encapsulada em um
envelope SOAP. Sendo assim, UDDI utiliza toda a infra-estrutura já
existente para garantir a universalidade;
 Descrição – UDDI descreve o serviço especificando as interfaces,
ferramentas protocolos e tipos de valores do mesmo, além disso, também
descreve as funcionalidades do Web Service. A descrição das variáveis e
seus tipos e valores não descreve o sentido da existência do Web Service,
isto é, o seu propósito. A capacidade de descrição da tecnologia UDDI se dá
pela utilização de palavras-chave e pequenas tags de descrição,
possibilitando que se informe a todos exatamente o que o serviço pode
oferecer tanto no sentido de quais são os dados disponíveis, como de quais
são os melhores dados a serem utilizados para o serviço em questão;
 Descoberta – UDDI oferece mecanismos de busca para descoberta de
serviços nele publicado. Buscas como por palavra-chave relativa ao que se
deseja encontrar, retornando assim uma lista de resultado relevante.
Também é possível que se examine a pequena descrição existente em cada
registro dos serviços listados pela busca, permitindo que se tenha certeza
que um serviço listado está realmente de acordo com os requisitos do
consumidor desse serviço. Essa tecnologia possui APIs para listagem de
serviços pertencentes a um registro, assim como para a inserção de um
serviço no mesmo;
 Integração – o repositório facilita a integração entre sistemas através de
todas as operações UDDI, sendo assim tornando possível que aplicações
obtenham maior funcionalidade utilizando Web Services registrados no
repositório.
FIGURA 2 - Modelo de fluxo de um processo de requisição a um repositório UDDI.
(FONTE: Web Service Architecture. W3C, 2006b. Documento que define a arquitetura da tecnologia
Web Service. Disponível em < http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#gengag>.
Acesso em: 15 jan. 2006).
A Figura 2 apresenta o modelo de fluxo de mensagens e comunicação entre o
repositório UDDI o provedor (Web Service) e consumidor (cliente):
(1) Passo um:
(a) Provedor disponibiliza no repositório o seu serviço;
(b) Cliente requisita ao repositório uma pesquisa de serviços (através de
SOAP);
(c) Repositório retorna a descrição do serviço (documento WSDL).
(2) Provedor e cliente concordam com a mesma semântica do serviço.
(3) Cliente ou provedor constroem uma mensagem para seu destinatário
obedecendo à semântica;
(4) Ocorre a interação e troca de mensagens entre o provedor e consumidor;
2.6 Java Web Services
A plataforma Java Enterprise Edition (Java EE) disponibiliza uma série de
recursos para o desenvolvimento de aplicações que utilizem a tecnologia Web
Services. Nesta seção é feita uma breve descrição destas tecnologias e suas
funcionalidades.
2.6.1 Java Web Services Developer Pack
O Java WSDP ou então Kit de desenvolvimento de Web Services para Java,
é um conjunto integrado de ferramentas para o desenvolvimento, teste e implantação
de aplicações para Web, aplicações baseadas em XML e Web Services, com as últimas
implementações dos padrões Web Services para a plataforma Java. A sua versão atual
é a 2.0, que inclui ferramentas que tornam o desenvolvedor capaz de (SUN
MICROSYSTEMS, 2006i):
 Desenvolver e implantar aplicações usando as últimas tecnologias XML e
Web Services, incluindo suporte para a plataforma de aplicações da SUN
Microsystems;
 Aumentar o desempenho de Web Services desenvolvidos com a versão 1.6
do Java WSDP, sem a necessidade de nenhuma alteração no código da
aplicação;
 Criar aplicações baseadas em XML e Web Services que utilizem os padrões
de segurança XML Web Services Security;
 Aproveitar do uso da plataforma Java para desenvolver aplicações Web
Services, sua interoperabilidade e toda sua infra-estrutura já existente;
 Simplificação e redução de custos na integração de aplicações legadas, na
troca de dados e na publicação de recursos e serviços na Web.
O lançamento da versão 2.0 do Java WSDP contém as novas
implementações de tecnologias já existentes em versões anteriores do Java WSDP,
como: JAX-WS 2.0 (Java API for XML Web Services), JAXB 2.0 (Java API for XML
Binding) e SAAJ 1.3 (SOAP with Attachments API for Java), este conjunto de
tecnologias é chamado de integrated stack (pilha integrada) para Web Sevices. Juntos
esses três componentes representam uma nova arquitetura para desenvolvimento que
estabelece uma maior lógica entre os relacionamentos da descrição de Web Services,
ligação dos dados do serviço e processamento de SOAP com anexos.
O resultado disso é uma plataforma de desenvolvimento ágil, fácil, mais
eficiente e mais reusavel. Entretanto para compatibilidade de aplicações desenvolvidas
com versões anteriores o JAX-RPC (Java API for XML-Based RPC) também foi
incluído no pacote. O intuito da tecnologia JAX-WS é a substituição do JAX-RPC.
Também foi incluída nessa versão uma tecnologia experimental, JAX-WSA (Java API
for Web Services Addressing) que é a implementação da especificação WS-Addressing
da W3C (SUN MICROSYSTEMS, 2006i).
2.6.2 Java API for XML Web Services
A API Java para XML e Web Services (JAX-WS) é o centro da nova
arquitetura do Java WSDP, também conhecida como pilha integrada (integrated
stack), isto inclui o JAX-WS 2.0, JAXB 2.0 e SAAJ 1.3. A pilha integrada representa a
arquitetura lógica das funcionalidades dos Web Services. O JAX-WS foi desenvolvido
para tomar o lugar da tecnologia JAX-RPC nas aplicações Web que fazem uso de Web
Services.
Em versões anteriores do Java WSDP havia um problema no mapeamento
de dados XML para a aplicação, pois o JAX-RPC provia um mapeamento fraco de
dados, comparado ao JAXB, pois o JAX-RPC incluía o mapeamento básico dos tipos,
enquanto o JAXB podia mapear XML Schemas, o que torna mais fácil separar as
definições Web Services dos componentes da aplicação. O resultado disso é uma
arquitetura de desenvolvimento fácil de entender, desenvolver e de incorporar essa
tecnologia na aplicação (SUN MICROSYSTEMS, 2006b).
2.6.3 Java API for XML-Based RPC
O JAX-RPC é útil para o desenvolvimento de aplicações Web e Web
Services, incorporando a elas funcionalidades chamadas de procedimentos remotos
baseados em XML, de acordo com a especificação SOAP 1.1.
Entretanto, com o lançamento do Java WSDP 2.0 é melhor começar um
planejamento de migração para as novas tecnologias, como JAX-WS 2.0, JAXB 2.0 e
SAAJ 1.3 que são mais modernas, fáceis de programar e completamente integradas.
Porém a implementação do JAX-RPC será continuada e disponível no Java WSDP por
motivos de compatibilidade de aplicações antigas e, também, para facilitar o processo
de migração e transição para a nova tecnologia (SUN MICROSYSTEMS, 2006c).
2.6.4 Java API for XML Registries
A API Java para Registros XML (JAXR) provê um meio uniforme e
padronizado para o acesso de diferentes tipos de registros XML. Um registro XML é
uma estrutura capas de construir, implantar e descobrir Web Services.
Atualmente, existe uma variedade de especificações para registros XML,
incluindo ebXML (desenvolvido pela OASIS e U.N./CEFACT) e a especificação
UDDI. JAXR habilita os desenvolvedores Java a usar uma única API de fácil uso para
acessar uma variedade de registros XML, através de modelos que descrevem o
conteúdo contido em um registro XML. Também provê capacidades de classificação,
associação e consulta. A atual versão do JAXR inclui suporte detalhado ao ebXML e a
especificação UDDI 2.0 (SUN MICROSYSTEMS, 2006a).
2.6.5 Java Architecture for XML Binding
Arquitetura Java para ligamento XML (JAXB) provê um modo conveniente
de ligar um XML Schema a uma representação em código Java. Isto torna mais fácil
incorporar dados XML e funções para o seu processamento em aplicações Java sem
precisar saber muito sobre o XML em si. JAXB 2.0 está disponível no Java WSDP
2.0, faz parte da pilha integrada de tecnologias para desenvolvimento de Web Services.
Esta nova versão do JAXB inclui todas as funcionalidades de ligamento de XML em
um único pacote, enquanto na versão anterior era necessário trabalhar também com
JAX-RPC. A pilha de integrada de tecnologias (JAX-WS 2.0, JAXB 2.0 e SAAJ 1.3) é
uma arquitetura mais lógica, fácil e habilita o desenvolvimento de Web Service e
aplicações Web mais facilmente (SUN MICROSYSTEMS, 2006d).
2.6.6 SOAP with Attachments API for Java
A API Java para SOAP com anexos (SAAJ) prove um meio padronizado
para enviar e processar documentos SOAP com anexos pela Internet através da
plataforma Java. A atual versão do SAAJ é a 1.3 que está contida no pacote Java
WSDP 2.0 (SUN MICROSYSTEMS, 2006f).
2.6.7 XML and Web Services Security
Segurança em XML e Web Services (XWS-Security) é um framework que
faz parte do Java WSDP. Este provê um meio a desenvolvedores de aplicar segurança
em aplicações desenvolvidas com JAX-RPC, JAX-WS ou SAAJ, através de
conFigurações de políticas de segurança de requisição e resposta no nível de serviço,
porta ou operação. Esta implementação de XWS-Security provê segurança para Web
Services no nível de mensagem. Este framework implementa os padrões de segurança
em Web Services (WSS) propostos pela OASIS (SUN MICROSYSTEMS, 2006j).
2.7 Conclusão
A tecnologia de Web Services é um agregado de outras tecnologias, padrões
e protocolos que permitem a interoperabilidade entre sistemas distintos em um
ambiente heterogêneo. A arquitetura dos Web Services é baseada na arquitetura
cliente/servidor, que opera sobre requisições e respostas, as transmissões são feitas
pela Internet, entre um ponto a outro. O processo de trocas de mensagens entre o
provedor e o consumidor é realizado por um documento XML baseado no protocolo
SOAP que normalmente é transmitido sobre o protocolo HTTP. Este documento
trafega pela rede em texto plano até chegar ao receptor, estando passivo à
interceptação e leitura de seus dados por qualquer nó da rede que faça parte do
caminho a ser percorrido para alcançar o destinatário. Para evitar essa falha de
segurança é necessário estudar meios de aplicar técnicas de segurança no processo de
comunicação, para que este garanta a procedência, integridade e sigilo das
informações.
Neste capítulo se obteve o primeiro objetivo específico do trabalho, que é
apresentar os principais padrões envolvidos na especificação de Web Services. Com
isso, foram apresentandos dois componentes dos Web Services muito importantes para
o desenvolvimento do trabalho, o protocolo SOAP que é no qual são aplicadas as
políticas de segurança para o Web Services, e o WSDL, no qual estão contidos
informações descritoras sobre o serviço. Essas informações são necessárias para a
aplicação da segurança em determinadas operações expostas pelo Web Service.
Também, neste capítulo, foi possível perceber onde que as falhas de segurança são
encontradas na arquitetura.
3 SEGURANÇA EM WEB SERVICES
Este capítulo aborda as principais técnicas e tecnologias de segurança que
podem ser aplicadas em Web Services. A princípio é feita uma introdução teoria sobre
conceitos de segurança em uma aplicação, isto é, o que a torna segura ou não. Após,
são introduzidas as principais técnicas que podem ser usadas para garantir segurança
em uma aplicação, em conjunto com as tecnologias que as implementam. E,
finalmente, são citadas as principais organizações responsáveis pelo desenvolvimento
de tecnologias de segurança para Web Services e o que está disponível para a
plataforma Java.
3.1 Introdução
Confome o que já foi apresentado no capítulo anterior, Web Services é um
conjunto de tecnologias que podem reduzir a complexidade e custo na construção de
aplicações voltadas a negócios corporativos e, também, permitir novos modelos de
aplicações distribuídas.
Empresas que se interessam em trazer os Web Services para dentro de sua
arquitetura tem como fator de desmotivação a segurança, pois a intenção da tecnologia
Web Services é expor serviços ao ambiente externo. Segurança é importante para
qualquer nível organizacional em que o sistema atua, principalmente se este sistema
realiza transações sobre a Internet. Garantir a segurança nos Web Services é crucial
para adoção dessa tecnologia em um ambiente coorporativo, por razões de privacidade
financeiras, legislativas e de confiabilidade. Por isso, os Web Services precisam de
uma camada especial que garanta a segurança às transações por eles efetuadas.
Por que a necessidade de um nível especial de segurança para Web Services?
Por que não utilizar tecnologias já existentes e consolidadas na Internet como SSL
(Secure Sockets Layer), que é o mecanismo de segurança mais utilizado para
aplicações e-commerce? A resposta a essas perguntas é que a tecnologia Web Services
requer um nível de segurança fim-a-fim, ao invés do ponto-a-ponto que é provido pelo
SSL.
Uma segurança ponto-a-ponto é definida como segurança máquina-amáquina, isto é, a segurança é obtida no processo de comunicação de duas entidades
na rede. Deduz-se, então, que a segurança é aplicada no processo de transporte da
mensagem e não na mensagem em si, que é o caso da segurança fim-a-fim, que aplica
segurança no nível da mensagem (SUN MICROSYSTEMS, 2006i).
Web Services trabalham com trocas de mensagens. Elas podem ser de destino
ponto-a-ponto, como, por exemplo, uma requisição de um cliente e a resposta de um
servidor. Porém, também podem operar sobre a troca de mensagens fim-a-fim, onde
um cliente faz requisição a um serviço e este por sua vez se torna cliente de outro
serviço, que faz requisições a outro serviço utilizando os dados do cliente. Neste
cenário é impossível definir um meio de segurança ponto-a-ponto, pois a mensagem
utiliza de vários serviços para ser concluída e devolvida ao cliente.
3.2 Visão geral sobre segurança
Segundo HENDRICKS et al, (2002), o W3C (World Wide Web Consortium)
considera três grupos de riscos de segurança relacionados a aplicações na Internet:
 Segurança no servidor: falhas ou problemas na configuração do servidor.
Que permitam aos usuários remotos não autorizados se apropriem de
documentos confidenciais. Que executem comandos ou ações no servidor
que lhes dêem liberdade de modificar o sistema do servidor. Que obtenham
informações confidenciais do servidor que lhes permitam invadir o sistema;
 Segurança no cliente: conteúdo ativo que danifica e trava o sistema do
cliente, viola sua privacidade ou apenas lhe causa aborrecimentos;
 Segurança na rede: interceptação de dados enviados na rede pelo cliente ao
servidor ou vice-versa através de escuta clandestina da rede. Tornando
possível que os invasores operem através de qualquer ponto na trajetória da
rede entre o cliente e o servidor;
Para minimizar essas falhas, devem-se tomar vários cuidados ao se
disponibilizar uma aplicação na Web. Tais como atualizações de software e de sistema
operacional, utilização de um firewall, configuração adequada, entre outros. Para que
uma aplicação Web seja considerada segura, esta deve implementar alguns (se não
todos) serviços de segurança. Através desses serviços que se define a segurança em
uma aplicação. São seis requisitos que uma aplicação segura deve oferecer: identidade
e autenticação, autorização, integridade, privacidade e não-repúdio (HENDRICKS et
al., 2002).
3.2.1 Identificação e autenticação
Segundo HENDRICKS et al. (2002), a identificação e a autenticação lançam
uma pergunta a ser respondida pelo serviço de segurança: quem é você e como se sabe
se a sua identidade é legítima?
Através de informações como nome de usuário (login) e senha (password)
que se pode definir a identidade de um usuário remoto, baseado em uma base de dados
sobre usuários, pode-se fazer uma verificação ou pesquisa onde se procura um usuário
previamente cadastrado que condiz com as informações obtidas da requisição. Esse é o
processo mais comum de autenticação de um usuário, através de senhas.
Porém há outras tecnologias em desenvolvimento que possibilitam a
autenticação e identificação de usuários utilizando-se da biometria. Segundo a
enciclopédia virtual livre Wikipédia biometria é o estudo estatístico das características
físicas ou comportamentais dos seres vivos. Recentemente este termo também foi
associado à medida de características físicas ou comportamentais das pessoas como
forma de identificá-las unicamente. (http://pt.wikipedia.org/wiki/Biometria) Métodos
como
impressão
digital,
reconhecimento
da
face,
identificação
pela
íris,
reconhecimento
pela
retina,
reconhecimento
de
voz,
geometria
da
mão,
reconhecimento da assinatura e reconhecimento da digitação, podem ser usados como
recursos para a identificação e autenticação de pessoas ou usuários em um sistema.
Este é o ponto de entrada ao sistema, onde se verifica quem pode entrar ou
não. Caso a autenticação seja bem sucedida, o usuário pode prosseguir para a próxima
etapa que seria a autorização, caso contrário, o sistema rejeitará a tentativa da entrada e
opcionalmente poderá registrar a tentativa de acesso, obtendo informações sobre quem
a realizou para futuramente, caso haja necessidade de uma auditoria ou o não-repúdio.
3.2.2 Autorização
Segundo HENDRICKS et al, (2002), um serviço de autorização deve
responder à pergunta: você tem permissão para acessar esses dados/executar essa
transação?
Depois de efetuada a identificação e autenticação do usuário, este passa pelo
processo de autorização, que permite ou não o acesso a determinado recurso ou
sistema. Cada sistema possui a sua própria política de autorização, implementada
conforme sua necessidade.
Normalmente, usuários são definidos em grupos em um sistema, e a esses
grupos que são atribuídas certas permissões de execução ou acesso. Também outros
sistemas possibilitam atribuir permissões diretamente a usuários, tornando-os distintos
de outros usuários do mesmo grupo.
Outro esquema de permissões é através de papéis. Onde não existem
usuários ou grupos, apenas papéis em um sistema. A esses papéis são definidas
permissões, tais como: conectar, executar, administrar, recursos e outros. Nesse
esquema de papéis, um papel pode ser passivo ou não de conexão, o que pode ser
similar a um usuário ou um grupo, esse papel pode ter várias permissões e restrições
atribuídas a ele. Outros papéis podem ser criados por meio de herança, baseando-se em
um papel já existente e herdando todas suas características, o que é similar a um grupo.
3.2.3 Integridade
Segundo HENDRICKS et al, (2002), o serviço de integridade responde a
pergunta: os dados que você me enviou são os mesmos que eu recebi?
O serviço de integridade tenta garantir que os dados não sejam alterados ou
corrompidos durante o processo de transporte, em relação a sua fonte original. Como é
sabido, a Internet é um ambiente inseguro, ela não oferece garantia de integridade dos
dados que nela trafegam. Por isso, é essencial um mecanismo que garanta tal
integridade dos dados.
A uma série de tecnologias que tentam resolver esse problema, muitas delas
utilizam criptografia ou assinaturas digitais. No contexto de Web Services, vários
recursos e especificações foram desenvolvidos para implementar esse serviço de
segurança nesse tipo de aplicação. Como Web Services faz uso extenso de XML para
transportar suas mensagens, a melhor técnica de aplicar segurança é nessa camada da
sua arquitetura.
O W3C especificou desenvolveu o padrão que visa aplicar assinatura digital
em um documento XML. XML Signature é definido pelo seu Working Group (grupo
de trabalho responsável pelo desenvolvimento de uma especificação no W3C) como
um conjunto de sintaxes e de regras de processamento para criação e representação de
assinaturas digitais em documentos XML (W3C, 2006c).
3.2.4 Privacidade
Ninguém leu os dados que trocamos? Essa pergunta é respondida pelo
serviço de privacidade de uma aplicação. Uma comunicação privada é uma
comunicação em que somente os interessados podem ler os dados transmitidos por ela.
É essencial que se ofereça confidencialidade em uma comunicação privada. Como, por
exemplo, em uma transação on-line em um site de compras, onde é informado o
número do cartão de crédito do cliente, esse tipo de transação requer uma privacidade
de dados pessoais, segundo HENDRICKS et al. (2002), onde informações relativas à
pessoa não podem ser lidas por outros.
Também há outro cenário, como uma conversa através de um sistema de
bate-papo on-line, onde não se é desejado que a troca de mensagem seja interceptada e
lida por outras pessoas, esse tipo de situação é definido por HENDRICKS et al, (2002)
como privacidade de comunicação pessoal.
A criptografia é usada em larga escala para suprir a necessidade de
privacidade nas comunicações. O W3C desenvolveu o padrão que visa aplicar
criptografia em um documento XML. XML Encryption, segundo os representantes
deste Working Group, tem como objetivo desenvolver um processo de criptografar e
decriptografar um documento XML ou parte dele, usando sintaxe XML para
representação de conteúdo criptografado e de informações que possibilitem a
decriptografia deste documento (W3C, 2006d).
3.2.5 Não-repúdio
Segundo HENDRICKS et al. (2002), um serviço de não-repúdio deve estar
capacitado a responder a seguinte pergunta: como provar para terceiros que você
enviou os dados para eles – e recebeu – dados idênticos?
O serviço de não-repúdio procura provar a existência de uma transação ou
troca de informações através de subsídios gerados por esse serviço. Não-repúdio é um
meio de monitorar tudo o que acontece no sistema, para que sejam geradas evidências
de todos os eventos ocorrentes.
Um exemplo claro disso é um sistema de logging em um aplicativo Web,
onde, que cada requisição externa gera um registro de ocorrência e é informado quem
está requisitando tal serviço. Porém, há uma necessidade de validar tais informações
para que estas não possam ser forjadas ou declaradas falsas por falta de autenticidade.
Um meio de resolver esse problema é fazendo uso de assinaturas digitais, certificadas
e validadas por uma autoridade certificadora.
3.3 Técnicas e tecnologias de segurança
Através da implementação dos serviços de segurança uma aplicação, sendo
ela voltada para Web ou não pode ser considerada segura. Porém, para implementar
esses serviços é necessário o uso de tecnologia que forneçam meio para atender os
requisitos impostos por esses serviços. Atualmente, várias técnicas e tecnologias foram
ou estão sendo desenvolvidas para prover meio de segurança em uma aplicação.
Vários institutos de normalização técnica como IETF (Internet Engineering Task
Force), W3C (World Wide Web Consortium) e OASIS (Organization for the
Advancement of Structured Information Standards) fornecem padrões e especificações
para aplicar segurança no ambiente da Internet de um meio interoperável.
Cada serviço de segurança necessita de uma ou mais tecnologias para ser
implementado na aplicação. Privacidade necessita de criptografia, não-repúdio
necessita de logging e assinatura digital, integridade também necessita de assinatura
digital, autorização pode usar certificados digitais associados a identificação e
autenticação.
3.3.1 Criptografia
A Criptografia é a ciência que trata da preservação dos dados privados. Na terminologia
criptográfica, esses dados são chamados de textos simples ou puros. A codificação dos
dados, de maneira que os dados tornem-se ininteligíveis para os que venham a interceptálos, é chamada de criptografia. Esses dados criptografados são chamados de texto cifrado
(ciphertext). O processo de reconversão do texto cifrado para texto puro é chamado de
descriptografia. A criptografia e a descriptografia geralmente usa uma chave, sendo que o
método de codificação exige que se conheça a chave certa, para que a descriptografia possa
ser executada (HENDRICKS et al., 2002).
Algoritmos criptográficos funcionam baseados em chaves para efetuar a
criptografia e a decriptografia. Há duas classes de algoritmos e o que difere entre eles
são as chaves que estes usam para efetuar sua tarefa (HENDRICKS et al. 2002):
 Algoritmos simétricos: a peculiaridade dos algoritmos simétricos para
criptografia é que os mesmos utilizam da mesma chave para o processo de
criptografia e descriptografia, essa chave secreta deve ser compartilhada
entre todos os interessados;
 Algoritmos assimétricos: funciona baseado no princípio de duas chaves, a
chave pública e a chave privada, uma chave para criptografia e outra para
desriptografia. Onde a privada não é compartilhada e a pública sim;
3.3.1.1 Criptografia simétrica
O processo de criptografia simétrica é simples, há um emissor que deseja
enviar uma mensagem secreta ao receptor, o emissor escreve a mensagem, criptografa
a mesma com a chave secreta que ambos (emissor e receptor) conhecem. Após isso, o
emissor envia a mensagem criptografada ao receptor, este por sua vez, após receber a
mensagem a decriptografa. Este processo é ilustrado na Figura 3.
FIGURA 3 - Criptografia simétrica.
(HENDRICKS et al., 2002)
A criptografia simétrica foi o primeiro método concebido para criptografar
dados. Segundo DEITEL et al. (2003), a primeira cultura a fazer uso da criptografia
foi a cultura egípcia. Estes trocavam mensagens escritas a mão e aplicavam algoritmos
de criptografia sobre essas mensagens. Este povo utilizava de dois tipos de algoritmos
de criptografia simétrica, o algoritmo de substituição e algoritmos de transposição.
Os algoritmos de substituição são algoritmos simples para gerar textos
cifrados por meio de substituição de silabas, por exemplo, toda letra “a” é substituída
pela letra “b” e toda letra “b” é substituída pela letra “c” e assim consecutivamente, a
palavra “security” criptografada sobre esse algoritmo ficaria “tfdvsjuz”.
Os algoritmos de transposição trabalham da seguinte forma, toda palavra a
ser criptografada gerará duas palavras cifradas. Por exemplo, com a palavra “security”
a primeira letra é “s”, esta será a primeira letra da primeira palavra, a segunda letra é
“e” e será a primeira letra da segunda palavra, a terceira letra é “c” e será a segunda
letra da primeira palavra, e assim consecutivamente. O resultado da palavra “security”
criptografada com algoritmo simétrico de transposição seria “scrt euiy”.
Estes são apenas algoritmos criptográficos similares aos primeiros a serem
utilizados, de fácil compreensão para seres humanos e que são aplicados sobre textos e
caracteres. Os meios modernos de se aplicar criptografia a documentos eletrônicos são
digitais, trabalham diretamente com bits ou blocos de bits do documento. Utilizam
algoritmos complexos de criptografia a baixo nível, e a sua chave é caracterizada pelo
seu tamanho em bits, por exemplo, 128-bits ou 256-bits de tamanho da chave.
Nestes níveis, um computador moderno de bom desempenho poderia levar
um bom tempo para descobrir o segredo da chave e decriptografar a mensagem, esse
método de decriptografia é chamado de “ataque a força bruta” (brutal force) onde um
ou mais computadores tentam através de tentativa e erro descobrir a chave de um
documento criptografado (DEITEL et al., 2003).
A criptografia simétrica é muito eficiente e difícil de ser violada, porém
possui uma falha, a chave secreta precisa ser compartilhada por ambas as partes
interessadas na troca de mensagens criptografadas, então a chave secreta deixa de ser
secreta. Através de lógica e bom censo deduz-se que um segredo só é seguro quando
ninguém sabe. Baseado nessa necessidade é que a criptografia assimétrica foi
concebida.
3.3.1.2 Criptografia assimétrica
O processo de comunicação privada pela criptografia assimétrica é simples.
A entidade possui um par de chaves geradas por ela mesma ou por um CA (Certificate
Authorities). O par é constituído de duas chaves, a chave privada e a chave pública. O
que uma chave escreve, somente a outra pode ler, isto é, se a entidade “A” utilizar a
chave pública da entidade “B” para lhe enviar uma mensagem, somente a chave
privada de “B” poderá decodificar essa mensagem. E se “B” escrever uma mensagem
com sua chave privada, somente quem tem posse da sua chave pública poderá ler, este
é o principio de assinaturas digitais, que será abordado no item sobre assinatura digital
deste capítulo. Este processo é descrito e exemplificado na Figura 4 (DEITEL et al.,
2003).
FIGURA 4 - Criptografia assimétrica.
(HENDRICKS et al., 2002)
As autoridades certificadoras (CA) são abordadas com maior detalhe no item
sobre certificados digitais deste capítulo.
A criptografia assimétrica foi criada para sanar as falhas apresentadas na
criptografia simétrica, como a necessidade de troca da chave secreta, ausência de
mecanismos de manuseio e gerenciamento de chaves, falta de autenticidade e nãorepúdio.
A necessidade de troca da chave secreta é eliminada por meio de troca de
chaves públicas, sendo que cada entidade que necessite escrever uma mensagem, usará
a chave pública do destinatário para escreve-la, desta maneira somente o destinatário
poderá ler a mensagem escrita com a sua chave privada.
A ausência de mecanismos de manuseio e gerenciamento de chaves é
resolvida através da ICP (Infraestrutura de chave pública) ou em inglês PKI (Public
Key Infrastructure). Segundo HENDRICKS et al. (2002), a PKI é a coleção dos
serviços necessários para se gerar e gerenciar pares de chave pública/privada, assim
como para emitir e gerenciar certificados digitais e gerenciamentos do ciclo de vida da
chave.
A autenticidade e não-repudio é resolvida pela criptografia assimétrica da
seguinte maneira, no momento em que a entidade escreve uma mensagem, a mesma
afirma sua autenticidade pelo processo de escrita com a sua chave privada, pois
somente com a chave pública dessa entidade que é possível de decifrar a mensagem
escrita.
Porém, a criptografia assimétrica também tem sua desvantagem, que é o
desempenho. Esta é muito onerosa para computadores, mesmo os mais modernos da
atualidade.
Segundo GOODWIN (2004), é usado um truque chamado Handshake, que é
a troca inicial de chaves públicas entre duas entidades, após a troca uma das duas
entidades gera uma chave simétrica para criptografar o conteúdo da comunicação, essa
chave é criptografada com a criptografia assimétrica das chaves públicas e é trocada
entre as duas entidades, apartir deste momento na comunicação somente é usado a
chave simétrica. É impossível determinar perante o ambiente externo que tipo de
criptografia é usado no processo de comunicação. Então com esse método de
combinação é obtido o melhor das duas categorias de criptografia, a segurança e
privacidade da criptografia assimétrica e o desempenho da criptografia simétrica. O
processo de Handshake é melhor descrito pela Figura 5.
FIGURA 5 - Processo de Handshake.
O processo de Handshake é descrito nos seguintes passos (GOODWIN,
2004):
1. É gerada aleatoriamente pela entidade emissora uma chave simétrica;
2. É feita a troca de chaves públicas para a comunicação utilizando a criptografia
assimétrica;
3. O emissor de posse da chave pública do receptor que foi obtida no passo dois,
criptografa a chave simétrica por ele gerada aleatoriamente;
4. É feito o envio da chave simétrica criptografada do emissor para o receptor;
5. É descriptogradafa a chave simétrica com a chave privada do receptor, para as
futuras comunicações será usada a chave simétrica obtida no processo.
3.3.2 Assinaturas digitais
Assinaturas digitais visam resolver dois dos serviços ou requisitos de
segurança em que um sistema deve implementar, a integridade e identidade. A
criptografia assimétrica é uma tecnologia fundamental para a execução de assinaturas
digitais.
Segundo HENDRICKS et al. (2002), as assinaturas digitais servem, na
verdade, a dois propósitos:
 Conferir a integridade dos dados;
 Garantir a identidade do remetente;
HENDRICKS et al. (2002) citam que, de acordo com o Internet Security
Glossary da IETF (Internet Engineering Task Force), uma assinatura digital é:
Um valor computado com um algoritmo criptográfico e anexado a um objeto de dados, de
maneira que qualquer receptor de dados possa usá-la para verificar a origem e a integridade
dos dados. Os dados anexados a uma unidade de dados, ou uma transformação
criptográfica sobre eles, que permita que um receptor da unidade de dados comprove a
origem e a integridade da unidade de dados e proteja-se contra falsificações, por exemplo,
pelo receptor.
De acordo com HENDRICKS et al. (2002), uma assinatura digital costuma
ser criada pela computação de uma mensagem resumida a partir de um documento, e
concatenando-a com as informações sobre o assinante, um timestamp (carimbo de data
e hora), e qualquer outra informação útil. Uma função hash unidirecional é usada para
gerar a mensagem resumida, semelhante a um checksum, uma string de comprimento
fixo de números a partir de uma mensagem de texto de tamanho variável. O termo
unidirecional significa que transformar a string com tamanho fixo de volta para a sua
mensagem de texto é extremamente difícil. A string resultante é, então, criptografada,
com a chave privada do assinante que usa o algoritmo adequado. O bloco de bits
criptografado resultante é a assinatura.
A assinatura costuma ser distribuída juntamente com informações sobre a
chave pública que foi usada para assiná-la. Para verificar a assinatura, o receptor
primeiramente determina se ele tem certeza de que a chave pertence à pessoa a quem
supostamente pertença e, em seguida, decriptografa a assinatura usando a chave
pública da pessoa. Caso a assinatura seja decriptografada adequadamente e as
informações combinem com as da mensagem (resumo adequado da mensagem etc.),
assinatura é aceita como válida.
Este processo é descrito em passos para uma melhor compreensão na Figura
6, onde é ilustrado o processo de comunicação entre a entidade A e a entidade B, onde
a entidade A deseja enviar um documento assinado digitalmente à entidade B.
FIGURA 6 - Processo de assinatura digital de um documento.
O processo de assinatura digital de um documento é descrito nos seguintes
passos (GOODWIN, 2004):
1. A entidade A usa uma função hash unidirecional para computar o resumo de
seu documento.
2. Em seguida, a entidade A criptografa o resumo, usando sua chave privada,
com isso a mesma acaba de assinar digitalmente o documento.
3. Posteriormente, a entidade A criptografa sua assinatura digital, juntamente
com a mensagem original, usando a chave publica da entidade B.
4. O pacote criptografado é transmitido pela entidade A e recebido pela
entidade B.
5. A entidade B usa sua chave privada para descriptografar o pacote
criptografado, obtendo a mensagem e a assinatura digital.
6. A entidade B usa, então, a chave publica da entidade A para descriptografar
a assinatura para o resumo criado pela entidade A.
7. Usando o mesmo algoritmo hash unidirecional, a entidade B cria um novo
resumo a partir da mensagem do texto e então, comparado ao hash original.
Este último passo tanto confirma a integridade dos dados quanto garante a
identidade do remetente.
3.3.3 Certificados digitais
Segundo HENDRICKS et al. (2002), um certificado digital é um documento
que pode ser usado para identificar uma pessoa, servidor, empresa ou outra entidade.
Certificados digitais fornecem comprovação reconhecida através de terceiros que
confirmam esse certificado. Esses terceiros são chamados de Autoridades
Certificadoras, AC. Todo certificado digital gerado por um AC deve seguir as
seguintes características (HENDRICKS et al., 2002):
 Ligar uma chave pública a uma entidade que a identifica;
 Incluir o nome da entidade, a data de expiração, o nome da AC e o número
de serie do certificado;
 Sempre incluir a assinatura digital da AC emissora, para que usuários deste
certificado possam confiar no mesmo.
A AC assina o certificado criptografando o conteúdo da chave pública ou o
valor hash do mesmo com a sua chave privada. A AC deve verificar todas as
informações a serem armazenadas em um certificado antes de gerá-lo. Os usuários
devem confiar na chave pública da AC para verificar seu conteúdo e sua autenticidade.
Cada AC faz parte de uma hierarquia de autoridades certificadoras. Uma autoridade
certificadora faz parte de uma cadeia de ACs, partindo de um nó raiz, este nó raiz é a
autoridade de política de registros da Internet, IPRA (Internet Policy Registration
Authority).
É necessário mudar periodicamente o par de chaves para manter o sistema de
certificados seguro. Quanto mais tempo um par de chaves for usado, mais tempo o
mesmo se torna vulnerável, devido a técnicas de reconhecimento de padrões e análise
criptográfica. Devido a isso, um certificado digital é criado com uma data de
expiração, um tempo de validade, forçando o usuário a atualizar seu certificado. Se um
certificado for comprometido antes de sua data de expiração o usuário poderá obter um
novo apartir de seu CA.
Cada AC possui uma lista de certificados revogados, CRL (Certificate
Revocation List). CRLs armazenam apenas os certificados gerados por seus ACs. É
essencial que o usuário reporte ao seu AC se este desconfia de que seu certificado foi
comprometido, para que estes não sejam responsabilizados pelo mal uso de seus
certificados comprometidos.
DEITEL et al. (2003) afirmam que muitas pessoas consideram o e-commerce
inseguro. Entanto, transações usando certificados digitais podem ser mais seguro do
que trocas de informações privadas pelo telefone, por e-mail e até por pagamento de
cartão de crédito.
Segundo DEITEL et al. (2003), os algoritmos de segurança usados na
maioria dos casos de transações on-line são quase impossíveis de serem
comprometidos. As estimativas afirmam que estes algoritmos são tão seguros, que
seriam necessários milhões de computadores modernos trabalhando em conjunto
durante cem anos para quebrar a segurança destes algoritmos através de tentativa e
erro ou ataques de força bruta.
No entanto, DEITEL et al. (2003), ainda, afirmam que o poder da
computação aumenta significativamente durante os anos e que algoritmos
considerados seguros hoje podem ser quebrados no futuro.
3.4 Camadas de segurança em Web Services
Segundo SINGH et al. (2004), os serviços de segurança em Web Services
podem incluir segurança em nível de transporte e segurança em nível de mensagens.
A segurança sobre a camada de transporte é aplicada na camada em que o
Web Service atua, como HTTP, assegurando o processo de comunicação de um ponto
a outro. A segurança sobre a camada de mensagem é aplicada na mensagem em si, que
o Web Service transmite, através de tecnologias de criptografia e assinatura digital de
documentos XML.
Segundo a SUN MICROSYSTEMS (2006i), as principais necessidades de
segurança em um Web Service são:
 Baixo acoplamento entre o serviço e o consumidor;
 Segurança baseada em padrões da Internet;
 Uso de mensagens formadas XML;
 Foco em prover interoperabilidade;
 Neutralidade de plataforma e linguagem de programação;
 Possibilidade de utilizar vários protocolos de transporte, como HTTP,
SMTP, etc;
 Suporte a interação de vários intermediários entre o consumidor do serviço e
o provedor do serviço.
E as suas principais vulnerabilidades são (SUN MICROSYSTEMS, 2006i):
 Interações são efetuadas através da Internet, usando protocolos que são
amigáveis a firewalls;
 Uma comunicação é iniciada freqüentemente pelos consumidores do serviço
que não têm nenhum relacionamento prévio com o fornecedor de serviço;
 A mensagem é baseada em texto plano.
3.4.1 Segurança sobre a camada de transporte
DEITEL et al. (2002) afirmam que, atualmente, a maioria das aplicações
para comércio eletrônico usam Secure Socktes Layer (SSL) para suas transações online e o mesmo foi desenvolvido pela Netscape Communications, em um formato de
padrão aberto. SSL é comumente usado para garantir segurança em comunicações
entre dois computadores na Internet ou em uma rede. SSL opera entre os protocolos de
comunicação TCP/IP como está ilustrado pela Figura 7 e é transparente para a
aplicação que o utiliza.
FIGURA 7 - Processo de comunicação através do protocolo SSL.
O SSL utiliza a criptografia assimétrica e certificados digitais para autenticar
os servidores e clientes e proteger as informações que transitam pela Internet. O
processo de comunicação é iniciado pelo cliente, envia uma mensagem para o
servidor, o servidor responde a mensagem enviando o seu certificado digital ao cliente
para autenticação.
Usando a chave pública do servidor para se comunicar seguramente, o
cliente e o servidor negociam chaves simétricas para continuar a transmissão. Essa
chave é usada somente durante o processo da transação. Uma vez trocada a chave
simétrica a comunicação procede entre o cliente e o servidor usando esta chave. Dados
criptografados passam pelo canal de comunicação TCP/IP como qualquer pacote que
viaja pela Internet.
Entretanto, antes de mandar uma mensagem por TCP/IP o protocolo SSL
quebra a informação em blocos, comprime-a e a criptografa. Conseqüentemente para o
receptor, antes de o pacote chegar a aplicação o protocolo SSL a decriptografa o
pacote, descomprime-o e o monta para ser entregue a aplicação, tornado o processo
transparente (DEITEL et al., 2003).
Esses processos extras na comunicação provêem uma camada de segurança
entre aplicações que fazem uso do TCP/IP para se comunicar. O objetivo principal do
SSL é garantir a segurança de ponto a ponto em conexões ou transmissões de dados
para um computador a outro em uma rede, seja ela local ou remota, também provendo
meio de autenticação entre as duas partes (DEITEL et al., 2003).
O protocolo SSL provê para aplicações três serviços de segurança (DEITEL,
et al. 2003):
 Autenticação: o servidor apresenta ao cliente um conjunto de credenciais e
certificados que provam que este serviço é o que diz ser.
 Confidencialidade: os dados transmitidos por SSL são criptografados,
tornando impossível a legibilidade dos mesmos por terceiros que estejam no
caminho da comunicação entre o cliente e o servidor.
 Integridade: SSL garante um meio de verificação de que os dados por ele
transmitidos não foram alterados.
Segundo HENDRICKS et al. (2002), o SSL é um protocolo sofisticado que
está sendo muito usando na Internet, e que fornece uma boa camada de segurança, mas
que juntamente com outros serviços em nível de transporte, não deixa de apresentar
problemas quando aplicado à Web Services.
Múltiplos Web Services podem ser combinados para a formação de uma
aplicação maior, orientada a serviços, devido a isso esta aplicação necessita fazer
inúmeras chamadas e conexões com outros Web Services, e os mesmo podem também
fazer uso de outros Web Services e assim consecutivamente, o que torna o SSL um
padrão inapropriado para garantir a segurança de informações nesse tipo de sistema,
pois SSL provê segurança de ponto-a-ponto, máquina a máquina e não fim-a-fim como
é preciso neste caso, SSL não chega a descer para o próximo nível da cadeia de
serviços, ele fica apenas situado entre as conexões.
O protocolo SSL possui uma série de limitações quando se trata de sua
aplicabilidade em Web Services, que podem ser resumidas em (GOODWIN, 2004):
 SSL provê segurança de ponto-a-ponto e opera entre nós da rede (não entre
aplicações). Para Web Services é necessário segurança de fim-a-fim onde
nós intermediários podem existir entre um processo de troca de mensagem;
 SSL opera no nível de transporte e não no nível de mensagem. As
mensagens estão protegidas somente enquanto são transmitidas, não são
seguras por si só, necessitam de um canal seguro de comunicação;
 SSL não suporta não-repúdio. Não é possível provar que outra entidade
efetuou tal transação ou requisitou tal serviço;
 SSL não suporta criptografia customizada ou em parte. Utilizando SSL para
transportar um documento XML grande, seria necessário criptografa-lo por
completo, e não somente as informações que seriam consideradas
confidenciais.
Segundo HENDRICKS et al. (2002), a implementação de um Web Service
que faça uso de segurança sobre a camada de transporte HTTP com SSL é
razoavelmente simples. Ele afirma que não há necessidade de grandes alterações no
código da aplicação, apenas é preciso que se configure corretamente o servidor,
registrando um domínio seguro onde o Web Service está hospedado e obtendo um
certificado digital válido de uma AC para ser associado ao servidor. Para que isso
possa ser feito é necessário que o servidor onde a aplicação esteja hospedada suporte
comunicações através do protocolo SSL.
Porém, deve levar em consideração a carga extra de trabalho que o servidor
sofrerá para atender as requisições criptografadas por SSL, afirma DEITEL et al.
(2003). Existem soluções em hardware especializadas para tratar do processamento de
requisições SSL, como por exemplo, uma placa PCI que pode ser conectada ao
servidor e que fornece um processador que implementa a baixo nível o processamento
de SSL, afirmam DEITEL et al. (2003), fornecem um ótimo desempenho para a tarefa.
Baseado nas afirmações anteriores da SUN MICROSYSTEMS (2006i),
sobre as necessidades de segurança em Web Services, deduz-se que a segurança sobre
a camada de transporte não é a melhor tecnologia de segurança a ser aplicada nesse
tipo de sistema. Devido ao fato de ser dependente de protocolo de transmissão (HTTP)
e de não suportar a existência transparente de intermediários na comunicação. Porém,
pode ser aplicada com sucesso em um sistema que não necessite destas características
para o seu funcionamento.
3.4.2 Segurança sobre camada de mensagem
Segurança no nível de mensagem é diferente do que se usa geralmente para prover
segurança em Web Services hoje em dia. O que é feito hoje é pego a mensagem que é um
pedaço de dados vulnerável que todo mundo pode olhar, todo mundo pode mudar. Para
prever isso é pego esse pedaço de dados e a empurramos em um tubo de aço para o seu
destinatário que esta conectado na outra ponta do tubo. Esse tubo é o que chamamos de
segurança a nível de transporte que protege a mensagem entre a origem e seu destino.
Segurança no nível de mensagem é diferente, segurança a nível de mensagem pega esse
conjunto de dados e a embala em uma concha de do mesmo tipo de aço e agora a
mensagem esta segura por si só. Está segura antes de ser enviada, esta segura quando é
recebida e após ser recebida também. Agora não precisamos mais do tubo de aço. Agora
podemos usar qualquer tubo que temos disponível para mandar a mensagem. Também
podemos armazenar a mensagem depois de ser recebida, o que nos da à habilidade de
recuperá-la e verificar suas informações de segurança, como em situações com assinatura
digital, em que se quer provar que alguém quem mandou essa mensagem realmente é quem
diz ser. Estas características estão disponíveis para a sua aplicação, o que significa partir do
momento que se sabe o que a aplicação esta fazendo e da estrutura da mensagem, é
possível quebra-la e abri-la e se pode ver pedaços individuais da mensagem, pode-se
embala-los e criptografa-los, pode-se assina-los, assinar pedaços de diferentes formas,
pode-se embalar toda a mensagem, criptografa-la ou assina-la. Partindo disto, essa
tecnologia pode oferecer um ótimo meio de controle para a aplicação acessar um maior
conjunto de opções de segurança (GOODWIN, 2004).
Segundo a SUN MICROSYSTEMS (2006i), a segurança sobre a camada de
mensagem faz uso de uma série de mecanismos, tais como: criptografia, autenticação e
assinaturas digitais. As principais vantagens desse esquema de segurança na camada
da mensagem são:
 A segurança fica com a mensagem através de todos os nós e depois da
mensagem chegar ao seu destinatário;
 A segurança é granular, pode ser aplicada em diferentes partes da
mensagem, incluindo seus anexos;
 Pode ser usada em conjunto com intermediários na rede;
 É independente de ambiente e de protocolo de transporte.
3.4.2.1 Organizações envolvidas no desenvolvimento de tecnologias de segurança em
nível de mensagem para Web Services
Segundo a SUN MICROSYSTEMS (2006i), as seguintes organizações
trabalham para o desenvolvimento de especificações, tecnologias e ferramentas para
segurança em Web Services:
 The World Wide Web Consortium (W3C)
 XML Encryption: esta especificação provê requerimentos para o
processamento e criptografia de documentos expressados pela sintaxe
XML;
 XML Digital Signature: esta especificação define um meio de
representar assinaturas digitais em documentos XML através de sua
sintaxe e semântica;
 XML Key Management Specification: esta especificação define
protocolos para distribuição e registro de chaves públicas em
documentos XML;
 Organization for Advancement of Structured Information Standards (OASIS)
 Web Services Security (WSS), SOAP Message Security: Esta
especificação descreve aprimoramentos para o protocolo SOAP que
prove integridade, confidencialidade e autenticação na mensagem,
esta especificação será tratada com mais detalhes adiantes neste
capítulo;
 Security Assertion Markup Language (SAML): a especificação
SAML define um mecanismo baseado em XML para segurança de
transações B2B, B2C, e-commerce. SAML define um framework para
troca de informações sobre autenticação e autorização, desta forma
SAML provê um meio de interoperabilidade de definições de
segurança entre sistemas distintos;
 eXtensible
Access
Control
Markup
Language
(XACML):
a
especificação XACML define uma linguagem para expressão de
políticas de segurança baseado em documentos XML;
 Web Services Interoperability Organization (WS-I): diferente da W3C e da
OASIS, a WS-I desenvolve perfis de o que usar, e como usar as tecnologias
existentes para promover segurança em Web Services. Alguns desses perfis são:
 Basic Security Profile (BSP) que fornece um guia de uso do
framework WSS;
 REL Token Profile que é o guia de como usar a linguagem de
expressão de direitos (Rights Expression Language);
 SAML Token Profile: guia de uso da tecnologia SAML;
 Security Challenges, Threats, and Countermeasures (Desafios,
ameaças, e contramedidas de segurança): é um documento escrito pela
Web Services Interoperability Organization (WS-I), que visa
identificar ameaças de segurança em uma aplicação que faz uso de
Web Services em sua infra-estrutura. Este documento também visa
promover uma tecnologia apropriada para tratar essa ameaça.
3.4.2.2 API de segurança em nível de mensagem para Web Services na plataforma
Java
O framework responsável pela segurança em Web Services na plataforma
Java é o XWS-Security. Como já descrito no capítulo dois, o framework XWS-Security
faz parte do Java WSDP, este provê um meio a desenvolvedores de aplicar segurança
em aplicações desenvolvidas com JAX-RPC, JAX-WS ou SAAJ, através de
configurações de políticas de segurança de requisição e resposta no nível de serviço,
porta ou operação. Esta implementação de XWS-Security provê segurança para Web
Services no nível de mensagem e implementa os padrões de Segurança em Web
Services (WSS) propostos pela OASIS.
O framework XWS-Security fornece ao desenvolvedor de aplicações Web
Services uma ampla variedade de opções de definição de segurança em seu aplicativo.
O framework faz uso de uma série de tecnologias relacionadas que possibilita uma
configuração flexível e interoperável na camada de segurança do aplicativo.
O meio de se aplicar a segurança é através de arquivos XML de
configuração, usados em conjunto com o descritor da aplicação que é um documento
requerido em toda aplicação Enterprise para plataforma Java EE.
Segundo a SUN MICROSYSTEMS (2006i), uma aplicação Web Services
pode ser segura conforme os seguintes cenários:
 Assinando e verificando partes de uma mensagem SOAP e seus anexos
(fazendo uso da tecnologia XML Digital Signature);
 Criptografando ou descriptografando partes de uma mensagem SOAP e seus
anexos (fazendo uso da tecnologia XML Encryption);
 Enviando informações de identificação e autorização de usuários junto com
a mensagem SOAP (fazendo uso da tecnologia SAML).
3.5 Conclusão
Existem várias maneiras de se aplicar segurança em uma aplicação que faça
uso de Web Services. Pode-se utilizar métodos de segurança no ambiente de rede em
que o sistema atua, também pode-se aplicar segurança através da comunicação entre o
Web Service e seu consumidor. Porém, todas essas soluções possuem suas limitações,
o que as tornam impróprias para aplicação em determinados cenários. Por isso, a
tecnologia de segurança sobre a camada de mensagem está se tornando um padrão de
fato sobre a segurança em Web Services, devido a oferecer maior flexibilidade, opções
e configurações de segurança para os Web Services. Com o estudo realizado e as
conclusões tiradas sobre as tecnologias de segurança, opta-se por usar a segurança
sobre a camada de mensagem para o desenvolvimento deste trabalho devido ao nível
maior de flexibilidade na especificação de políticas de segurança e, também, por ser a
tecnologia desenvolvida especificamente para a realização da tarefa.
Este capítulo é de grande importância para o desenvolvimento do trabalho,
devido ao fato de que foram levantadas as possíveis soluções para o problema
abordados, realizando assim o segundo
objetivo específico deste trabalho, que é
levantar os principais recursos para aplicação de segurança em Web Services. Neste
capítulo que se pode decidir quais medidas devem ser tomadas para se garantir
segurança em um Web Serivces e, também, quais tecnologias que devem ser usadas
para a realização dessa tarefa.
4 ANÁLISE E MODELAGEM DO SISTEMA
Neste capítulo está a análise e modelagem do sistema desenvolvido visando
a exemplificação de um ambiente seguro com Web Services. O sistema consiste em
uma aplicação voltada ao comércio eletrônico do setor madeireiro do Planalto
Catarinense. A estrutura deste capítulo está organizada de acordo com a fase de
concepção do Processo Unificado – PU (sugerida por WAZLAWICK, 2004).
4.1 Concepção
Na fase de concepção é possível se ter uma noção exata do esforço
necessário para desenvolver o software, ou seja, o tamanho e a complexidade do
sistema (WAZLAWICK, 2004). É nesta fase que são organizadas e registradas as
informações obtidas a partir de reuniões com profissionais do setor madeireiro, com a
finalidade de se discutir o que o sistema precisa ter e o que este poderá fazer (SOUSA,
2005).
4.2 Sumário executivo
O sistema de e-commerce para o setor madeireiro visa fornecer aos seus
clientes meios de efetuar consultas e compras de produtos oferecidos pela empresa.
Também fornece operações administrativas do sistema tais como: cadastros de
materiais, clientes e consulta de vendas.
O sistema disponibiliza suas operações através de Web Services para que seja
possível a fácil integração com outros sistemas no futuro. Porém será necessário o
desenvolvimento de técnicas de segurança para que a realização destas operações
possam ser consideradas seguras, pois estas envolvem informações confidenciais da
empresa e dos clientes da mesma.
4.3 Levantamento de requisitos
A etapa de levantamento de requisitos corresponde a buscar, junto ao usuário
do sistema, todas as informações possíveis sobre as funções que o sistema deve
executar e as restrições sob as quais o sistema deve operar (WAZLAWICK, 2004).
Nesta seção, são descritos os requisitos funcionais (tudo o que o sistema deve fazer) e
os não-funcionais (restrições sobre como o sistema deve realizar seus requisitos
funcionais) (SOUSA, 2005).
Uma possível estrutura para a tabela de requisitos, segundo WAZLAWICK
(2004), pode ter os seguintes campos:
a) Código do requisito funcional (F seguido de um número e do nome do
requisito funcional: especificação curta);
b) Descrição (especificação longa e detalhada do requisito);
c) Categoria funcional: evidente (efetuados com o conhecimento do usuário) ou
oculto (efetuados pelo sistema sem o conhecimento explícito do usuário);
d) Código do requisito não-funcional (NF seguido do número do requisito
funcional, acrescido de um ponto, do número seqüencial do requisito nãofuncional e do nome do requisito não-funcional: especificação curta);
e) Restrição: especificação (longa) do requisito não funcional;
f) Categoria: indica o tipo de restrição, que pode ser de segurança, desempenho,
compatibilidade, especificação, interface etc.;
g) Obrigatoriedade: se o requisito é desejável ou obrigatório;
h) Permanência: se o requisito é permanente ou transitório (permanente nunca
mudará com o tempo).
i) O * indica obrigatoriedade do dado.
O Quadro 5 fornece as informações de Clientes que deveram ser mantidas no
sistema. Informações pessoais e de acesso (login/senha) deverão ser mantidas no
sistema para que se possa autenticar um cliente ou então saber qual endereço que
deverá ser entregue a mercadoria comprada pelo mesmo.
QUADRO 4 - Cadastro de Clientes
F1 Manter Cadastro de Clientes
Oculto ()
Descrição: Permite incluir, excluir, alterar e consultar as informações sobre clientes.
Requisitos Não Funcionais
Nome
Restrição
Categoria
Desejável
Permanente
N.F. 2.1
As informações sobre o cliente são:
Informações do nome*; sobrenome*; endereço(rua,
cliente
numero, bairro, cidade, estado, cep, Especificação
complemento)*; cpf *; login*;
password*.
N.F. 2.2
O cliente deve ser identificado pelo
Identificação do seu cpf ou seu login.
Interface
cliente
N.F. 2.2
O cliente deve ter um login e este
Especificação
Login do cliente deve ser unico.
X
X
X
O Quadro 5 fornece os dados relevantes sobre o cadastro de Produtos. É
importante ter um conjunto de registros de Produtos, para que se possa obter um
relatório de produtos, um controle de estoque e saber o que será possível disponibilizar
para venda aos Clientes.
QUADRO 5 - Cadastro de Produtos
F2 Manter Cadastro da Produtos
Oculto ()
Descrição: Permite incluir, excluir, alterar e consultar as informações sobre produtos.
Requisitos Não Funcionais
Nome
Restrição
Categoria
Desejável
Permanente
N.F. 3.1
As informações sobre o produto
Informações do são: nome*; preço por unidade*;
Produto
quantidade em estoque*
identificador*.
N.F. 3.2
O produto deve ser identificado
Identificação do pelo seu nome ou identificador.
Produto
Especificação
X
Interface
X
O Quadro 6 apresenta a principais informações sobre a realização de uma
Ordem de Compra, esta armazena o Cliente que a realizou, sua data de realização e
uma lista de Produtos que a compõem.
QUADRO 6 - Cadastro de Ordem de Compra
F3 Manter Cadastro de Ordem de Compra
Oculto ()
Descrição: Permite incluir, excluir, alterar e consultar as informações sobre ordem de compra.
Requisitos Não Funcionais
Nome
Restrição
Categoria
Desejável
Permanente
N.F. 4.1
Informações da
Ordem de
compra
N.F. 4.2
Identificação da
Ordem de
compra
N.F. 4.3
Realização da
Ordem de
Compra
As informações sobre a ordem de
compra são: cliente*;
Especificação
produtos/quantidade*; data da
realização*;
A Ordem de compra deve ser
identificada pelo seu identificador.
Interface
A Ordem de compra deve ser
realizada somente por um cliente.
Especificação
X
X
X
O Quadro 7 apresenta as informações relativas a Categoria de um produto,
esta entidade categoriza o produto, por exemplo, um produto “Porta de cedro” pertence
a categoria “Portas” que é medido por unidade. Então, baseado nisso, uma Categoria
deve ter um nome e uma unidade que classificam os produtos.
QUADRO 7 - Cadastro de Categoria
F5 Manter Cadastro de Categoria
Oculto ()
Descrição: Permite incluir, excluir, alterar e consultar as informações sobre Categoria.
Requisitos Não Funcionais
Nome
Restrição
Categoria
Desejável
Permanente
N.F. 4.1
Informações da
Categoria
N.F. 4.2
Identificação da
Categoria
As informações sobre
administrador são: nome*;
Especificação
unidade*; identificador*;
A categoria deve ser identificada
pelo seu identificador ou seu nome. Interface
X
X
4.4 Lista de consultas
A geração de relatórios e consultas não precisa ser considerada um caso de
uso do sistema, pois não alteram a informação registrada no sistema. Basta definir o
formato em que a informação deve ser exibida e definir um modo padrão para o
usuário gerar os relatórios. Desse modo, os relatórios e consultas só são listados na
fase de concepção, visando uma construção em etapa posterior (SOUSA, 2005). A
lista de consultas referente a esse sistema é apresentada no Quadro 8.
QUADRO 8 - Lista de consultas
Nome
Referências cruzadas
Acessado por
Produto
F1, F5
Cliente
F4,
Ordem de compra F1, F2, F3, F4, F5
Categoria
Administrador, Cliente
Administrador
Administrador, Cliente
(somente as realizadas por ele).
Administrador, Cliente
F1, F4
4.5 Requisitos suplementares
De acordo com WAZLAWICK (2004), os requisitos suplementares, podem
ser definidos pelos mesmos campos usados no levantamento de requisitos, a única
diferença está na numeração, já que os requisitos suplementares não estão associados a
requisitos funcionais. A numeração, neste caso, é feita com o prefixo S seguido de um
número. A lista de requisitos suplementares é apresentada no Quadro 9.
QUADRO 9 - Requisitos suplementares
Nome
S1 Níveis
segurança
Restrição
Categoria
de O ambiente possui 2 níveis de
segurança:
Nível 1- (Administrador) Acesso a
todas as informações- permite incluir,
consultar, alterar, excluir qualquer
informação e autorizar usuário;
Nível 2 – (Cliente) permite consultar
produtos, categorias e realizar ordem de
compra.
Segurança
O sistema deverá ser desenvolvido para
plataforma Java EE.
Arquitetura
S3 Formas de O ambiente deverá ser acessado através
acesso
de Web Services.
Arquitetura
S4 Banco
Dados
Arquitetura
S2 Plataforma
de O Banco de Dados deverá
compatível com o padrão SQL92.
ser
S5 Autenticação Todas as operações a serem realizadas
devem ser autenticadas e autorizadas.
S6 Privacidade
Todos os dados transmitidos devem ser
criptografados.
Desejável Permanente
X
X
X
X
Segurança
X
Segurança
X
Nome
Restrição
Categoria
S7 Não-repúdio Toda realização de uma Ordem de
compra deve ser assinada digitalmente
pelo cliente.
Segurança
Desejável Permanente
X
4.6 Organização de requisitos
Essa etapa serve para estruturar os requisitos para que possam ser abordados
nos ciclos de desenvolvimento e é composto pelos artefatos e lista de casos de uso,
lista de conceitos com operações cadastrais, planejamento dos ciclos iterativos,
cronograma e glossário, descritos nos próximos subitens (SOUSA, 2005).
4.6.1 Listas de caso de uso
Segundo WAZLAWICK (2004), o objetivo de listar os casos de uso, é
levantar informações sobre como o sistema interage com possíveis usuários e quais
consultas e transformações da informação são necessárias, além daquelas já
identificadas na fase de levantamento de requisitos.
Para auxiliar na abordagem das informações correlacionadas com o sistema
segue o Quadro 11 de caso de uso do sistema em questão. A divisão do sistema feita
através de casos de uso resulta em uma melhor compreensão do sistema e facilita na
definição das funções de cada usuário.
QUADRO 10 - Lista de caso de uso
Nome
Atores
Realizar uma
Cliente
Ordem de Compra
Descrição
Referências Cruzadas
O cliente faz uma requisição ao
sistema informando os produtos que o
F4, F3, F2
mesmo deseja comprar, juntamente
com seu cartão de credito.
4.6.2 Lista de conceitos e operações cadastrais
Na lista de conceitos com operações cadastrais (Quadro 11), é possível fazer
a associação das diversas funcionalidades do sistema, sabendo quando uma é prérequisito para que a outra possa acontecer, bem como definir o que o usuário pode
fazer (incluir, alterar, excluir, consultar) com as informações disponibilizadas no
sistema, e sob quais condições (SOUSA, 2005).
QUADRO 11 - Lista de operações cadastrais
Conceito
I A E C Observação
Cliente
X X X X
Produto
X X X X
Ordem de
Compra
X
Categoria
X X X X
X X
Atributos: nível de segurança*, login*, senha*,
confirmar senha*.
Um cliente só pode ser inserido por um administrador.
O cliente apenas podera efetua o caso de uso de Ordem
de Compra.
O cliente poderá efetuar consultas sobre Produtos e suas
Categorias.
O cliente poderá efetuar consultas somente em Ordem
de Compra que estiverem associadas a ele.
A alteração, exclusão ou inserção de Produto poderá ser
realizada somente por um administrador.
A criação de uma nova Ordem de Compra poderá
somente ser realizada por um Cliente através do caso de
uso.
A alteração, exclusão ou inserção de Categorias poderá
ser realizada somente por um administrador.
Referências
Cruzadas
F1, F2, F3,
F4, S5, S6,
S7
F3, F1
F1, F3, F4,
S5, S6, S7
F3, F1
4.7 Fase de elaboração
Segundo WAZLAWICK (2004), a fase de elaboração se inicia com uma fase
de análise e prossegue com a face de projeto, e a fase de análise em si, comporta três
atividades distintas realizadas na seguinte ordem:
a) Expansão dos casos de uso e determinação dos eventos de sistema.
b) Construção do modelo conceitual.
c) Elaboração dos contratos das operações de sistema.
Nesta seção é apresentado somente a expansão do caso de uso e o modelo
conceitual, os contratos do sistema não são apresentados devido a baixa complexidade
do mesmo, sendo que somente com as informações obtidas na expanção de caso de
uso já é suficiente para a implementação do sistema.
No Quadro 12 s apresentado a expansão do caso de uso Ordem de Compra,
que descreve o funcionamento desta operação.
QUADRO 12 - Expansão do caso de uso Ordem de Compra
Caso de Uso: Realizar Ordem de Compra
Ator: Cliente
Interessados: Cliente.
Precondições: Cliente deve estar registrado no sistema. Os produtos que constituem a ordem de compra
devem estar registrados no sistema e também que estejam disponíveis no estoque da empresa.
Pós -condições: Depois de efetuada a compra, deve ser registrada essa negociação e é dado baixa no
estoque da empresa dos produtos que foram vendidos.
Requisitos correlacionados: F1, F3, F4, S5, S6, S7
Variações Tecnológicas: a identificação do Cliente é feita através de assinatura digital e os dados devem
ser criptografados.
Questões em aberto: não há.
Fluxo principal:
Passos
1. O cliente envia uma requisição de compra com as seguintes informações:
1. Sua identificação (login/senha);
2. Sua lista de produtos a serem comprados;
3. Seu número de cartão de credito;
4. Sua assinatura digital do documento;
2. O sistema analiza a resquisição do cliente:
1. O sistema verifica a sua identificação;
2. O sistema verifica a disponibilidade dos produtos contidos na lista da ordem de compra;
3. O sistema valida o crédito do cliente;
3. O sistema da baixa no estoque da empresa;
4. O sistema credita o crédito do cliente na conta da empresa;
5. O sistema retorna ao cliente uma mensagem de operação bem sucedida;
Fluxo alternativo:
2.1.a: Caso a identificação falhe o sistema retorna uma mensagem de erro sobre a identificação;
2.2.a: Caso não exista algum produto na lista de compra o sistema retorna um erro informando essa
condição;
2.2.b: Caso não haja disponibilidade de algum produto contido na lista de compra, o sistema retorna um
erro informando essa condição;
2.3.a: Caso o cartão de crédito do cliente seja inválido, o sistema retorna um erro informando essa
condição;
2.3.b: Caso não haja crédito na conta do cliente o sistema retorna um erro informando essa condição;
Na Figura 8 é apresentando o modelo conceitual do sistema, onde apresenta
o conjunto de entidades que o compõem.
FIGURA 8 - Modelo de conceitual.
4.8 Fase do projeto
Segundo WAZLAWICK (2004), a fase de projeto enfatiza a proposta de uma
solução que atenda aos requisitos da análise. Então, se a análise é uma investigação
para tentar descobrir o que o cliente quer, o projeto consiste em propor uma solução
com base no conhecimento adquirido na análise.
O projeto deste sistema é constituído de uma breve descrição da aplicação,
um diagrama de classes que compoem o sistema e uma descrição dos Design Patters
utilizados na implementação.
4.8.1 Descrição do sistema
O sistema foi desenvolvido na plataforma Java EE, onde é disponibilizado
em um servidor de aplicação. Este servidor de aplicação disponibiliza ao sistema um
ambiente de execução seguro e com uma série de recursos necessários para sua
execução. Como, por exemplo, controle de transações, conectividade a um banco de
dados relacional e ao ambiente externo.
O sistema é acessado somente pela tecnologia Web Services, suas operações
cadastrais, consultas e casos de uso. Devido a necessidade dessa arquitetura, a
implementação dessas funcionalidade é feita de modo a fazer uso de uma
granularidade grossa dos dados. É reduzido ao máximo a interação do cliente ao
serviço, isto é, as chamadas do métodos expostos pelo Web Service conter todos os
dados necessários para realização da operação.
Por exemplo, no caso do caso de uso Ordem de Compra, a requisição para a
operação contém informações do cliente, informações do seu crédito financeiro e todos
os produtos que este deseja comprar. Com esse conjunto de informações o sistema
pode determinar se a operação é ou não efetuada com sucesso, sem a necessidade de
novas interações com o cliente. Esse método de granularidade grossa é necessário em
sistemas que fazem uso de Web Services devido a latência entre uma requisição e
resposta entre o cliente e o servidor, ou vice-versa.
São implementados dois Web Services, um para o Cliente e outro para o
Administrador. Cada um destes fornecer operações que visam atender as necessidade
de cada um desses atores, descobertas na fase de análise.
Todas a transmissões de dados devem ser confidenciais ao meio externo,
sendo assim, os Web Services farão uso extenso de criptografia e também qualquer
acesso ao sistema deve ser autenticado e autorizado.
A realização do caso de uso Ordem de Compra deve ser assinada pelo
cliente, para que futuramente seja possível a realização de uma auditoria e, também
fornecer subsídios para o não-repúdio de uma compra efetuada.
4.8.2 Arquitetura do sistema
O sistema baseia-se em uma arquitetura Cliente/Servidor onde os Clientes da
aplicação são o Administrador e o Cliente da camada de domínio. Cada um destes
Clientes fará acesso remoto pela rede a suas operações do sistema através de Web
Services. Todos os dados transmitidos entre o Cliente e o Servidor devem ser
confidenciais ao meio externo. O sistema implementa mecanismos de autenticação e
autorização de Clientes através dos Web Services. Também há a necessidade
específica, no caso da operação Ordem de Compra, onde será necessária a validação
de identidade do Cliente que a efetuar. No caso, é utilizada assinatura digital do
documento que representa a reaquisição de uma Ordem de Compra.
A Figura 9 apresenta a arquitetura do sistema:
FIGURA 9 - Arquitetura do sistema
O ponto crítico de segurança identificado nessa arquitetura é que o sistema
disponibiliza operações de lógica de negócios ao ambiente externo. Tais operações
estão carregando dados que comprometem tanto a empresa como o cliente que está
solicitando o serviço. O sistema deve se precaver e prevenir que entidades não
autorizadas venham a executar operações indevidamente.
4.8.3 Diagrama de classes
A Figura 10 apresenta o diagrama de classes, de acordo com a UML, para o
sistema de comércio eletrônico da indústria madeireira.
FIGURA 10 - Diagrama de classe.
Este diagrama foi concebido a partir do modelo conceitual obtido na fase de
elaboração do sistema. Normalmente no diagrama de classe é específicado o
comportamento de cada classe através de seus métodos. Neste caso, esses métodos
foram omitidos presando a simplicidade do diagrama, pois, toda a lógica do sistema
não está contida nessas classes, e sim nas classes referentes a fachada do sistema, que
será abordada na seção sobre a fachada do sistema deste capítulo, cabendo a essas
classes apenas servir como uma cápsula dos dados manipulados pelo sistema.
WAZLAWICK (2004) prevê a necessidade de um modelo lógico de banco
de dados em um projeto que faça uso do processo unificado. Na Figura 11 é
apresentado o modelo lógico do banco de dados relacional.
FIGURA 11 - Modelo lógico do banco de dados
4.9 Padrões de projeto utilizados
Para a implementação deste sistema são utilizados alguns padrões de projeto
(Design Patterns) que facilitaram este processo.
Os padrões se referem à comunicação de problemas e soluções. Em outras
palavras, os padrões permitem documentar um problema conhecido recorrente e sua
solução, em um contexto específico, e comunicar esse conhecimento para outras
pessoas.
Um dos elementos-chave na declaração anterior é a palavra recorrente, visto
que a meta do padrão é promover uma reutilização conceitual ao longo do tempo
(ALUR, CRUPI e MALCKS, 2004).
O sistema é separado em duas camadas: a camada de modelo, onde será
representado todas as entidades do sistema, tais como Clientes, Produtos, Ordem de
Compra e Adminstradores e a camada de serviços disponibiliza as operações expostas
pelo sistema ao meio externo, onde, cada ator do sistema (Cliente e Administrador)
pode realizar suas devidas operações.
O sistema faz uso do design pattern listado no catálogo J2EE, Session
Fachade para camada de serviços abordado por ALUR, CRUPI e MALCKS (2004).
4.9.1 Session Fachade
Session Fachade, trata de duas questões: controle de acesso do cliente aos
objetos de negócio e limitação do tráfego de rede entre clientes remotos e serviços de
negócios de granulação fina (ALUR, CRUPI e MALCK, 2004). Session Fachade visa
eleminar uma série de problemas que podem aparecer em um aplicativo coorporativo,
tais como:
 Elimina a dependência direta entre o cliente e o serviço, o que se chama de
acoplamento fraco;
 Elimina responsabilidade de conhecimento da lógica de negócio por parte do
cliente,
questões
como
conhecimento
de
relacionamentos
entre
componentes, controle de transações e segurança;
 Possibilita a fácil integração de diferentes tipos de clientes ao aplicativo;
 Reduz o tráfego de rede, devido ao projeto de acesso a camada de negócio
por granulação grossa.
Para o sistema desenvolvido, o Session Fachade é representado pelo próprio
Web Service, pois este permite um acesso simplificado do meio externo para a lógica
da aplicação, disponibilizando operações simples para execução de tarefas de
complexidade alta, como por exemplo, uma Ordem de Compra.
Foram desenvolvidas duas fachadas para o sistema, uma para o
Administrador e outra para o Cliente, onde cada uma destas contem a lógica de
negócio necessária para realização das tarefas incubidas aos atores.
A Figura 12 apresenta o diagrama de classes que ilustra a relação das
fachadas com o modelo do sistema e também as operações expostas por este.
FIGURA 12 - Diagrama de classe do padrão Session Fachade.
4.10 Conclusão
Neste capítulo foi apresentado o projeto e modelagem do sistema de
comércio eletrônico do setor madeireiro. Este processo foi baseado no modelo
proposto por WAZLAWICK (2004) do Processo Unificado, no qual, através dessa
etapa, foi possível analisar os principais requisitos para a implementação do sistema,
pertinentes ao assunto tratado neste trabalho, que é de grande importância, pois a
definição do sistema que rege sua implementação e implantação no ambiente. Também
foi neste capítulo que se definiram as regras e políticas de segurança que o sistema
deve seguir.
Porém, não se deve esquecer que o principal objetivo do mesmo é propor
uma metodologia prática de aplicabilidade de segurança em aplicações que façam uso
de Web Services. O sistema foi projetado com o intuito de fornecer um ambiente
propício para demonstração de um ambiente seguro com Web Services, devido a isso
foram omitidas algumas informações que seriam importantes para o desenvolvimento
de um sistema real para este setor.
5 DESENVOLVIMENTO E CONFIGURAÇÃO DO SISTEMA.
Neste capítulo é explanado o desenvolvimento do sistema proposto no
capítulo anterior e, também, a configuração adequada do ambiente para que propicie a
execução correta do mesmo. Por fim, é feita uma demonstração do ambiente seguro,
comparando-se com uma aplicação sem a tecnologia de segurança.
5.1 Requisitos de software
Os requisitos de software abrangem todos os softwares necessários para a
construção e execução do sistema. A lista abrange ambientes de desenvolvimento,
sistema gerenciador de banco de dados, servidor de aplicação e APIs e frameworks.
Segue abaixo a lista necessária de softwares do sistema:
 Java Standard Edition Developer Kit 5 (ambiente necessário para execução
e compilação de aplicações Java);

XML Web Service Security 2.0: conjunto de APIs para aplicar segurança na
camada de mensagem dos Web Services;
 Sun Java System Application Server Platform Edition 9 (servidor de
aplicação que implementa a especificação Java EE 5);
 PostgreSQL 8.1 (sistema gerenciador de banco de dados compatível com o
padrão SQL92);
 eclipse 3.2 (ambiente de desenvolvimento integrado para a plataforma
Java);
5.2 Instalação e configuração do ambiente
A instalação e configuração do ambiente é uma etapa delicada a implantação
do software desenvolvido, também é sábido que para se desenvolver um sistema devese ter um ambiente de desenvolvimento previamente configurado e instalado
adequadamente, para que possibilite a realização de testes no tempo de
desenvolvimento.
Seguem abaixo os passos a serem realizados em ordem da configuração do
sistema:
5.2.1 Instalação do Java Standard Edition Developer Kit 5 e configuração das
variáveis de ambiente:
Para a instalação correta da plataforma Java Standard Edition Developer Kit
5 (JDK 5) deve-se configurar duas variáveis de ambiente no sistema operacional
hospedeiro, a variável JAVA_HOME, que deve referenciar o diretório de instalação do
JDK 5, e a variável PATH, que deve ser acrescida do valor JAVA_HOME\bin, que
indica o caminho para as ferramentas de linha de comando distribuídas em conjunto
com Java SE 5 necessárias posteriormente para o desenvolvimento.
5.2.2 Instalação do PostgreSQL 8.1:
A instalação do SGDB PostgreSQL 8.1 deve ser padrão conforme indica o
instalador da aplicação. Para se obter maiores detalhes do processo de instalação
recomenda-se visitar o site http://www.postgresql.org.br.
Após a instalação, deve ser criado um banco de dados e um usuário/senha,
ambos com o nome de segurança-ws, esse banco deve estar vazio, sem nenhuma
tabela, pois estar será geradas pelo SJSAS 9 na hora do deploy da aplicação (devido ao
fato da aplicação utilizar a tecnologia JPA (Java Persistence API, detalhes dessa
tecnologia serão explicados na seção sobre a camada de persistência).
5.2.3 Instalação do eclipse 3.2:
Para instalar o eclipse 3.2 basta extraí-lo em uma pasta do sistema
operacional, com o Java SE 5 devidamente configurado e o eclipse executará sem
problemas, após a sua primeira execução a ferramenta ira pedir o caminho do diretório
que seram armazenados os projetos. Este diretório deve ser qualquer um válido no
sistema.
Após configurado o diretório de projetos, deve-se criar dois projetos, um
para o cliente do Web Service e outro para o servidor do Web Service. Também devese configurar devidamente as bibliotecas de ambos os projetos (a lista de bibliotecas é
descrita na seção sobre arquivos de configuração do sistema).
5.2.4 Instalação do Sun Java System Application Server Platform Edition 9
A instalação do servidor de aplicação segue normalmente como o proposto
pelo seu instalador, após a conclusão dessa etapa, deve-se criar uma variável de
ambiente chamada AS_HOME que indique o diretório onde o servidor de aplicação foi
instalado.
Após
feito
isso
deve
ser
AS_HOME\domains\domain1\lib
o
copiado
arquivo
para
o
diretório
postgresql-8.1-
404.jdbc3.jar que é o drive do SGDB PostgreSQL, do qual o SJSAS 9 irá
necessitar para estabelecer uma conexão com o banco de dados, o arquivo se encontra
no diretório: <diretorio de instação do PostgreSQL 8.1>\jdbc.
Após isso é necessário reiniciar o servidor de aplicação.
Após o reinício é necessário criar uma fonte de dados (Data Source) que será
disponibilizada pelo SJSAS 9 para a aplicação conectar ao banco de dados contido no
PostgreSQL 8.1. Para fazer isso é necessário acessar a ferramenta administrativa do
servidor, o Admin Console, que é acessado através de uma página localizada no
endereço http://localhost:4848, para isso é preciso que o servidor esteja
ativo.
Após
o
login
na
página
administrativa,
deve-se
abrir
o
nó
Resources\JDBC da árvore Application Server (localizada a esquerda da
pagina).
Neste
nó,
encontram-se
dois
sub-nós,
JDBC
Resources
e
Connection Pools. Primeiro é necessário criar um novo Connection Pool,
para isso deve-se entrar no nó correspondente e clicar no botão New (localizado sobre
a tabela de lista de Pools). Depois disso apararecerá uma tela de cadastro do novo
Connection Pool, com três campos a serem preenxidos, Name (o nome do
Connection Pool), Resource Type (tipo de recurso, mais especificamente, a
classe que o mesmo representa) e Data Base Vendor (SGDB). A propriedade
Name terá o valor seguranca-ws-postgresql, o Resource Type será
javax.sql.DataSource e o Data Base Vendor será PostgreSQL.
Após criado o Connection Pool é hora de criar o JDBC Resource,
para fazer isso deve-se acessar o sub-nodo JDBC Resource, clicar no botão New e
indicar o JNDI name e o Pool Name, o Pool Name é o mesmo que foi
previamente criar no cadastro do Connection Pool, o JNDI name é o nome
dado para o recurso que está sendo criado, e através desse nome que a aplicação terá
acesso a este recurso, no caso o nome será jdbc/Seguranca-WS-DS.
5.3 Codificação do sistema
Nesta seção é demonstrado como foi codificada a parte lógica do sistema,
que envolve a camada de domínio, persistência e fachada do sistema.
5.3.1 Camada de domínio
A camada de domínio, como descrito no capítulo anterior, é a camada que
representa a inteligência do sistema, suas entidades e dados por ele manipulados, todos
em um paradigma orientado a objetos.
A camada de domínio foi projetada baseada em uma análise feita sobre uma
empresa madeireira, gerando uma série de documentações, entre elas um diagrama de
classes. Este diagrama representa graficamente a estrutura das classes do sistema, com
base nele que foram codificadas as classes da camada de domínio.
O diagrama prevê a necessidade de seis classes: Endereço, Cliente,
OrdemCompra,
Categoria,
ProdutoOrdemCompra
e
Produto. Os
relacionamentos entre elas são descritos no diagrama de classes.
Essas classes foram codificadas usando o padrão Java Beans, proposto pela
especificação da SUN MICROSYSTEMS segundo BATES e SIERRA (2006). Para
representar os relacionamentos entre elas, foi utilizado o framework Collections do
Java SE, que objetiva disponibilizar uma serie de classes para representar coleções de
objetos, tais como, listas, conjuntos, mapas, filas, pilhas e etc. segundo BATES e
SIERRA (2006).
Porém há algo a mais na codificação destas classes, que são as anotações
(annotations) da API JPA (Java Persistence API). Essas anotações referem-se ao
mapeamento entre o paradigma orientado a objeto da linguagem Java para o
paradigma relacional do padrão SQL92, essa técnica é chamada de mapeamento objeto
/ relacional, do inglês object / relational mapping (ORM), segundo BAUER e KING,
(2005). O que facilita o desenvolvimento de uma aplicação, pois abstrai o mapeamento
e persistência de objetos para um banco de dados, tarefa essa muito maçante, repetitiva
e bastante suscetível a falhas, afirmam BAUER e KING, (2005).
Toda classe que deseja ser persistida através da JPA deve:
 Ter uma anotação @Entity da JPA, que indica que esta classe é uma
entidade persistível;
 Ter uma anotação @Id da JPA sobre o campo que representará o
identificador desta classe, que pode ser um valor de significado semântico
para o objeto (por exemplo, um CPF para uma Pessoa) ou então não ter
significado algum, apenas representado o identificador do objeto (valor este
que pode ser gerado automaticamente ou não);
 Deve sobrescrever os métodos equals e hashcode da super classe
Object (não é uma necessidade de fato, porém é extremamente
aconselhável), o método equals deve verificar se uma instância de objeto
é igual a outra, e o hashcode é utilizado para gerar um código hash,
utilizando quando este objeto for usado de chave em um mapa da API
Collections, ambos os métodos deve ser sobrescritos somente quando se
utiliza a técnica correta, caso o contrário pode acarretar em falhas no
funcionamento da aplicação;
 Deve implementar a interface Serializable do pacote java.io (não é
uma necessidade de fato, porém é extremamente aconselhável).
 Deve ter um construtor sem parâmetros.
Baseado nessa série de regras e no diagrama de classe foram implementadas
as classes de domíno da aplicação. O Quadro 13 apresenta a implementação da classe
Endereço, essa classe não é uma entidade isolada, ele existe somente quando
associada a um Cliente, então ela utiliza-se da anotação @Embeddable que indica
que ela terá um relacionamento de cardinalidade um para um com a classe Cliente.
QUADRO 13 - Classe Endereço.
package net.uniplac.tcc.segurancaws.model;
import java.io.Serializable;
import javax.persistence.Embeddable;
@Embeddable
public class Endereco implements Serializable {
public Endereco() {}
private
private
private
private
private
private
String rua;
Integer numero;
String bairro;
String cidade;
String uf;
String cep;
public String getRua() {
return rua;
}
public void setRua(String rua) {
this.rua = rua;
}
public Integer getNumero() {
return numero;
}
public void setNumero(Integer numero) {
this.numero = numero;
}
public String getBairro() {
return bairro;
}
public void setBairro(String bairro) {
this.bairro = bairro;
}
public String getCidade() {
return cidade;
}
public void setCidade(String cidade) {
this.cidade = cidade;
}
public String getUf() {
return uf;
}
public void setUf(String uf) {
this.uf = uf;
}
public String getCep() {
return cep;
}
public void setCep(String cep) {
this.cep = cep;
}
}
O quadro 14 apresenta a implementação da classe Cliente, esta classe
segue as regras antes expostas para a implementação de uma entidade persistível para
a JPA. Também apresenta três diferenciais:
A
anotação
@NamedQueries
que
representa
o
conjunto
de
@NamedQuerie, uma @NamedQuerie é uma consulta pré-processada, escrita na
linguagem JPQL (Java Persistence Query Languare, (SUN MICROSYSTEMS,
2006g), liguagem própria para consulta em ORM;
 A anotação @Column(nullable=false, unique=true) que indica
que o valor da coluna mapeada não deve ser nulo e deve ser único;
 A
anotação
@OneToMany(cascade=CascadeType.ALL,
mappedBy = "cliente") que indica um relacionamento um para
muitos com um objeto OrdemCompra no atributo cliente.
Também, outro diferencial é a anotação @XmlTransient, que indica que
na hora da codificação do objeto para um documento XML que o atributo
ordensCompra não será codificado. A classe OrdemCompra (que será vista
posteriormente) tem um relacionamento com a classe cliente, devido a isso, uma das
duas classes devem abrir mão da propriedade relacionadora na hora da codificação em
XML, caso contrário o JAXB não consegue identificar o sinal de parada no grafo de
objetos relacionados, resultado em uma repetição eterna da codificação de dois objetos
relacionados bi-direcionalmente.
Infelizmente na versão do JAXB usada no trabalho não oferece o suporte
para relacionamentos bidirecionais entre dois objetos, resultado em uma dependencia
circular.
QUADRO 14 - Implementação da classe Cliente.
package net.uniplac.tcc.segurancaws.model;
import
import
import
import
import
import
import
import
import
import
java.io.Serializable;
java.util.Collection;
javax.persistence.CascadeType;
javax.persistence.Column;
javax.persistence.Embedded;
javax.persistence.Entity;
javax.persistence.Id;
javax.persistence.NamedQueries;
javax.persistence.NamedQuery;
javax.persistence.OneToMany;
@Entity
@NamedQueries( {
@NamedQuery(name = "Cliente.findByCpf", query = "SELECT c FROM Cliente c WHERE c.cpf =
:cpf"),
@NamedQuery(name = "Cliente.findByNome", query = "SELECT c FROM Cliente c WHERE c.nome =
:nome"),
@NamedQuery(name = "Cliente.findByLogin", query = "SELECT c FROM Cliente c WHERE c.login
= :login"),
@NamedQuery(name = "Cliente.findByPassword", query = "SELECT c FROM Cliente c WHERE
c.password = :password"),
@NamedQuery(name = "Cliente.findAll", query = "SELECT c FROM Cliente c"),
@NamedQuery(name = "Cliente.findByCidade", query = "SELECT c FROM Cliente c WHERE
c.endereco.cidade = :cidade"),
@NamedQuery(name = "Cliente.findByUf", query = "SELECT c FROM Cliente c WHERE
c.endereco.uf = :uf"),
@NamedQuery(name = "Cliente.findByCep", query
= "SELECT c FROM Cliente c WHERE
c.endereco.cep = :cep"),
@NamedQuery(name = "Cliente.findByBairro", query
= "SELECT c FROM Cliente c WHERE
c.endereco.bairro = :bairro"),
@NamedQuery(name = "Cliente.findByRua", query
= "SELECT c FROM Cliente c WHERE
c.endereco.rua = :rua")
})
public class Cliente implements Serializable {
@Id
@Column(nullable = false, unique = true)
private String cpf;
private String nome;
@Column(unique = true)
private String login;
private String password;
@Embedded
private Endereco endereco;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "cliente")
private Collection<OrdemCompra> ordensCompra;
public Cliente() {}
// getters and setters
@XmlTransient
public Set<OrdemCompra> getOrdensCompra() {
return this.ordensCompra;
}
public void addOrdemCompra(OrdemCompra ordemCompra) {
ordemCompra.setCliente(this);
getOrdensCompra().add(ordemCompra);
}
public int hashCode() {
int hash = 0;
hash += (this.cpf != null ? this.cpf.hashCode() : 0);
return hash;
}
public boolean equals(Object object) {
if (object == null || !this.getClass().equals(object.getClass())) {
return false;
}
Cliente other = (Cliente)object;
if (this.cpf != other.cpf && (this.cpf == null || !this.cpf.equals(other.cpf)))
return false;
return true;
}
public String toString() {
return getNome();
}
}
O Quadro 15 apresenta a implementação da classe Categoria, esta classe
apresenta um diferencial relativo as classes vistas até agora, ela possui seu
identificador gerado automaticamente pela JPA, isso é indicado através da anotação
@GeneratedValue(strategy=GenerationType.AUTO).
QUADRO 15 - Implementação da classe Categoria.
package net.uniplac.tcc.segurancaws.model;
import
import
import
import
import
import
import
import
import
import
import
java.io.Serializable;
java.util.Collection;
javax.persistence.CascadeType;
javax.persistence.Column;
javax.persistence.Entity;
javax.persistence.GeneratedValue;
javax.persistence.GenerationType;
javax.persistence.Id;
javax.persistence.NamedQueries;
javax.persistence.NamedQuery;
javax.persistence.OneToMany;
@Entity
@NamedQueries( {
@NamedQuery(name = "Categoria.findById", query = "SELECT c FROM Categoria c WHERE
c.idCategoria = :idCategoria"),
@NamedQuery(name = "Categoria.findByNome", query = "SELECT c FROM Categoria c WHERE
c.nome = :nome"),
@NamedQuery(name = "Categoria.findByUnidade", query = "SELECT c FROM Categoria c WHERE
c.unidade = :unidade"),
@NamedQuery(name = "Categoria.findAll", query = "SELECT c FROM Categoria c")
})
public class Categoria implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Integer id;
@Column(unique = true)
private String nome;
private String unidade;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "categoria")
private Collection<Produto> produtos;
public Categoria() {}
// getters and setters
@XmlTransient
public Set<Produto> getProdutos() {
return produtos;
}
public void addProduto(Produto produto) {
produto.setCategoria(this);
getProdutos().add(produto);
}
public int hashCode() {
int hash = 0;
hash += (this.id != null ? this.id.hashCode() : 0);
return hash;
}
public boolean equals(Object object) {
if (object == null || !this.getClass().equals(object.getClass())) {
return false;
}
Categoria other = (Categoria)object;
if (this.id != other.id && (this.id == null || !this.id.equals(other.id)))
return
false;
return true;
}
public String toString() {
return getNome();
}
}
O Quadro 16 apresenta a implementação da classe Produto, esta apresenta
apenas um diferencial as outras classes apresentadas anteriormente, que é a anotação
@ManyToOne que indica o relacionamento de muitos para um da classe Produto
para classe Categoria.
QUADRO 16 - Implementação da classe Produto.
package net.uniplac.tcc.segurancaws.model;
import
import
import
import
import
import
import
import
java.io.Serializable;
javax.persistence.Entity;
javax.persistence.GeneratedValue;
javax.persistence.GenerationType;
javax.persistence.Id;
javax.persistence.ManyToOne;
javax.persistence.NamedQueries;
javax.persistence.NamedQuery;
@Entity
@NamedQueries( {
@NamedQuery(name = "Produto.findByIdProduto", query = "SELECT p FROM Produto p WHERE
p.idProduto = :idProduto"),
@NamedQuery(name = "Produto.findByNome", query = "SELECT p FROM Produto p WHERE p.nome =
:nome"),
@NamedQuery(name = "Produto.findByPrecoUnitario", query = "SELECT p FROM Produto p WHERE
p.precoUnitario = :precoUnitario"),
@NamedQuery(name = "Produto.findByQdtEstoque", query = "SELECT p FROM Produto p WHERE
p.qdtEstoque = :qdtEstoque"),
@NamedQuery(name = "Produto.findByCategoria", query = "SELECT p FROM Produto p WHERE
p.categoria = :categoria"),
@NamedQuery(name = "Produto.findAll", query = "SELECT p FROM Produto p JOIN p.categoria
c")
})
public class Produto implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Integer id;
private String nome;
private Double precoUnitario;
private int qdtEstoque;
@ManyToOne
private Categoria categoria;
public Produto() {}
// getters and setters, equals, hashcode, toString...
}
O Quadro 17 apresenta a implementação da classe OrdemCompra, esta
apresenta dois diferenciais relativos as classes apresentadas anteriormente, que é a
anotação
@Temporal(TemporalType.DATE)
que
indica
que
o
campo
dataRealizacao do tipo java.util.Date será mapeado no banco de dados
como um tipo DATE do padrão SQL92 e a anotação @XmlElement sobre o método
getPrecoTotal(), isso indica que será criado no momento da codificação do
documento XML um elemento preco-total que armazena o valor total da Ordem
de compra.
QUADRO 17 - Implementação da classe OrdemCompra.
package net.uniplac.tcc.segurancaws.model;
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
java.io.Serializable;
java.text.DateFormat;
java.util.Collection;
java.util.Date;
javax.persistence.CascadeType;
javax.persistence.Entity;
javax.persistence.GeneratedValue;
javax.persistence.GenerationType;
javax.persistence.Id;
javax.persistence.ManyToOne;
javax.persistence.NamedQueries;
javax.persistence.NamedQuery;
javax.persistence.OneToMany;
javax.persistence.Temporal;
javax.persistence.TemporalType;
javax.xml.bind.annotation.XmlElement;
@Entity
@NamedQueries( {
@NamedQuery(name = "OrdemCompra.findByIdOrdemCompra", query = "SELECT o FROM OrdemCompra
o WHERE o.idOrdemCompra = :idOrdemCompra"),
@NamedQuery(name = "OrdemCompra.findByDataRealizacao", query = "SELECT o FROM OrdemCompra
o WHERE o.dataRealizacao = :dataRealizacao"),
@NamedQuery(name = "OrdemCompra.findByCliente", query = "SELECT o FROM OrdemCompra o JOIN
o.cliente c WHERE o.cliente = :cliente"),
@NamedQuery(name = "OrdemCompra.findAll", query = "SELECT o FROM OrdemCompra o JOIN
o.cliente c")
})
public class OrdemCompra implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Integer id;
private String cartaoCredito;
@Temporal(TemporalType.DATE)
private Date dataRealizacao;
@ManyToOne
private Cliente cliente;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "ordemCompra")
private Collection<ProdutoOrdemCompra> listaProdutoOrdemCompra;
public OrdemCompra() {}
// getters and setters, equals, hashcode, toString...
@XmlElement
public double getPrecoTotal() {
double soma = 0;
for (ProdutoOrdemCompra produtoOrdemCompra : getListaProdutoOrdemCompra())
soma += produtoOrdemCompra.getPrecoTotal();
return soma;
}
}
O Quadro 18 apresenta a última classe da camada de domínio, a classe
ProdutoOrdemCompra. Esta classe tem como propósito estabelecer um
relacionamento de N para N com entre as classes Produto e OrdemCompra.
QUADRO 18 - Implementação da classe ProdutoOrdemCompra.
package net.uniplac.tcc.segurancaws.model;
import
import
import
import
import
import
import
import
import
import
java.io.Serializable;
javax.persistence.Entity;
javax.persistence.GeneratedValue;
javax.persistence.GenerationType;
javax.persistence.Id;
javax.persistence.ManyToOne;
javax.persistence.NamedQueries;
javax.persistence.NamedQuery;
javax.xml.bind.annotation.XmlElement;
javax.xml.bind.annotation.XmlTransient;
@Entity
@NamedQueries( {
@NamedQuery(name = "ProdutoOrdemCompra.findByIdProdutoOrdemCompra", query = "SELECT p
FROM ProdutoOrdemCompra p WHERE p.idProdutoOrdemCompra = :idProdutoOrdemCompra"),
@NamedQuery(name = "ProdutoOrdemCompra.findByQtdVendido", query = "SELECT p FROM
ProdutoOrdemCompra p WHERE p.qtdVendido = :qtdVendido"),
@NamedQuery(name = "ProdutoOrdemCompra.findByOrdemCompra", query = "SELECT p FROM
ProdutoOrdemCompra p WHERE p.ordemCompra = :ordemCompra"),
@NamedQuery(name
=
"ProdutoOrdemCompra.findByProduto",
query
=
"SELECT
p
FROM
ProdutoOrdemCompra p WHERE p.produto = :produto"),
@NamedQuery(name
=
"ProdutoOrdemCompra.findOrdemCompraByProduto",
query
=
"SELECT
p.ordemCompra FROM ProdutoOrdemCompra p WHERE p.produto = :produto")
})
public class ProdutoOrdemCompra implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Integer id;
private int qtdVendido;
@ManyToOne
private OrdemCompra ordemCompra;
@ManyToOne
private Produto produto;
public ProdutoOrdemCompra() {}
// getters and setters, equals, hashcode, toString...
@XmlElement
public double getPrecoTotal() {
return getProduto().getPrecoUnitario() * qtdVendido;
}
@XmlTransient
public OrdemCompra getOrdemCompra() {
return this.ordemCompra;
}
}
5.3.2 Fachada do sistema
A fachada do sistema é a camada que será exposta ao consumidor dos
serviços, esta camada é composta de dois Web Services, um para expor os métodos
para o cliente e outro para o administrador.
Nesta seção são apresentadas duas interfaces que compõem a fachada do
sistema, a interface da fachada do cliente e a interface da fachada do administrador.
Optou-se por uma metodologia de separação da implementação da interface, que
possibilita mudar a implementação da fachada sem mudar sua interface com o cliente,
provendo maior flexibilidade na hora da implementação. O que é exposto ao Web
Service são apenas as interfaces, caso haja a necessidade de se esconder um método do
Web Service apenas retira-se da interface que a classe implementa, ou caso haja a
necessidade de mudar a implementação do codigo do Web Service, pode-se apenas
mudar as classes que implementam a interface, o que não ocasionará nenhuma
mudança para o consumidor do serviço.
Os Web Services foram desenvolvidos com a tecnologia JAX-WS 2.0
apresentada no capítulo dois, também como a camada de persistência JPA
(apresentada na próxima seção), o JAX-WS faz parte da nova especificação Java EE
5, sendo assim ambos usam anotações para descrever no código fonte atributos e
configurações necessárias para seus propósitos, JPA para persistência, JAX-WS para
Web Services.
Para se desenvolver Web Services com a tecnologia JAX-WS é necessário
seguir algunas regras propostas pela tecnologia:
 Toda classe ou interface que for exposta como um Web Service, precisa
conter a anotação de classe javax.jws.WebService;
 Cada método que a classe deseja expor como uma operação de um Web
Service deve conter a anotação javax.jws.WebMethod;
A seguir é apresentado as duas interfaces que compõem a fachada do
sistema.
O Quadro 19 apresenta a interface do Web Service Cliente, que contém todos
os operações expostas para o cliente, como foi definido no capítulo quatro. O atributo
targetNamespace da anotação @WebService indica qual o namespace utilizado
na geração do XMLSchema do Web Service.
QUADRO 19 - Interface que representa a Fachada do Cliente.
package net.uniplac.tcc.segurancaws.services;
import java.util.List;
import javax.jws.WebMethod;
import javax.jws.WebService;
import
import
import
import
net.uniplac.tcc.segurancaws.model.Categoria;
net.uniplac.tcc.segurancaws.model.OrdemCompra;
net.uniplac.tcc.segurancaws.model.Produto;
net.uniplac.tcc.segurancaws.model.ProdutoOrdemCompra;
@WebService(targetNamespace="http://services.segurancaws.tcc.uniplac.net")
public interface ClienteWebServiceIF {
@WebMethod(operationName = "recuperar-produtos")
public List<Produto> recuperarProdutos();
@WebMethod(operationName = "recuperar-categorias")
public List<Categoria> recuperarCategorias();
@WebMethod(operationName = "recuperar-ordens-de-compra")
public List<OrdemCompra> recuperarOrdensCompra(String username);
@WebMethod(operationName = "fazer-compra")
public void fazerCompra(List<ProdutoOrdemCompra> produtos,
Long cartaoCredito, String username) throws Exception;
}
O Quadro 20 apresenta a interface da fachada do Administrador, com todos
os seus métodos expostos no Web Service, segundo a definição da análise realizada no
capítulo quatro.
QUADRO 20 - Interface que representa a Fachada do Administrador.
package net.uniplac.tcc.segurancaws.services;
import java.util.List;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import
import
import
import
net.uniplac.tcc.segurancaws.model.Categoria;
net.uniplac.tcc.segurancaws.model.Cliente;
net.uniplac.tcc.segurancaws.model.OrdemCompra;
net.uniplac.tcc.segurancaws.model.Produto;
@WebService(targetNamespace="http://services.segurancaws.tcc.uniplac.net")
public interface AdministradorWebServiceIF {
@WebMethod(operationName = "recuperar-categorias")
public List<Categoria> recuperarCategorias();
@WebMethod(operationName = "recuperar-produtos")
public List<Produto> recuperarProdutos();
@WebMethod(operationName = "recuperar-clientes")
public List<Cliente> recuperarClientes();
@WebMethod(operationName = "recuperar-todas-ordens-de-compra")
public List<OrdemCompra> recuperarTodasOrdensCompra();
@WebMethod(operationName = "salvar-produto")
public void saveProduto(@WebParam(name = "produto") Produto produto)
throws Exception;
@WebMethod(operationName = "salvar-cliente")
public void saveCliente(@WebParam(name = "cliente") Cliente cliente)
throws Exception;
@WebMethod(operationName = "salvar-categoria")
public void saveCategoria(@WebParam(name = "categoria") Categoria categoria)
throws Exception;
@WebMethod(operationName = "excluir-produto")
public void deleteProduto(@WebParam(name = "produto") Produto produto)
throws Exception;
@WebMethod(operationName = "excluir-cliente")
public void deleteCliente(@WebParam(name = "cliente") Cliente cliente)
throws Exception;
@WebMethod(operationName = "excluir-categoria")
public void deleteCategoria(@WebParam(name = "categoria") Categoria categoria)
throws Exception;
}
O que resta as classes que irão implementar essas interfaces é indicar o
caminho
do
pacote
da
@WebService(endpointInterface=””)
interface
que
no
neste
atributo
caso
seria,
net.uniplac.tcc.segurancaws.services.ClienteWebServiceIF
para
implementação
do
Web
Service
do
cliente
e
net.uniplac.tcc.segurancaws.services.AdministradorWebServi
ceIF para o Web Service do administrador.
5.3.3 Camada de persistência
Na camada de persistência do sistema optou-se por utilizar a tecnologia JPA,
que oferece uma camada de abstração da persistência e também oferece uma
portabilidade de SGBD para a aplicação, pois quando é necessário mudar de banco de
dados, apenas muda-se a fonte de dados no servidor da aplicação, sem necessidade se
quer de reimplantar a aplicação no servidor. A persistência dos objetos é realizada nas
classes de implementação das interfaces dos Web Services, que serão vistas na seção
seguinte.
5.3.3.1 O arquivo persistence.xml
Para se construir uma aplicação que faça uso da JPA deve-se ter uma ou mais
classes devidamente configurada com anotações da JPA seguindo as regras
apresentadas na seção anterior sobre a camada de modelo, o que indicam que são
persistíveis e, também, deve-se ter um arquivo de configuração com nome de
persistence.xml dentro do diretório META-INF localizado no diretório raiz dos
binários das classes, por exemplo: temos o pacote org.model onde encontra-se
nossas classes persistíveis, dentro do diretório que contém o pacote org deve existir o
diretório META-INF com o arquivo persistence.xml.
O arquivo persistence.xml é documento XML, como pode-se ver no
Quadro 23, é constituído pelo elemento raiz persistence que contém N elementos
persistence-unit (neste caso somente um) cada elemento deste representa uma
unidade de persistência, que pode ser referenciada por um nome (atributo name) e
associada a um banco de dados diferente. Cada unidade de persistência precisa indicar
o tipo de transação que irá trabalhar, existem duas opções:

Controle de transações interna da aplicação (valor RESOURCE_LOCAL
do atributo transaction-type do elemento persistenceunit), que a própria aplicação faz controle transacional com o banco de
dados, através da API JPA;

Transações controladas pelo servidor de aplicação, que faz uso da API
de transações JTA (Java Transaction API, valor JTA do atributo
transaction-type do elemento persistence-unit). JTA é
um recurso poderoso e flexível que é disponibilizado para aplicações
hospedadas no servidor, com ele é possível controlar não só transações
com banco de dados, mas também em métodos e recursos internos e
externos, possibilitando uma combinação de todos.
Optou-se pelo uso do controle interno transacional para o desenvolvimento
deste sistema, devido a necessidade da aplicação em operar na especificação servlet
2.4 (a versão do XWSS 2.0 somente opera em servelt 2.4), o que torna impossível a
utilização da JTA que só é disponível na especificação servlet 2.5 (que traz suporte a
injeção de dependência).
JPA não um framework de persistência, é uma especificação, sendo assim
possível mudar sua implementação conforme o desejado, a implementação utlizada
pelo servidor é o framework Hibernate, devido ao fato de se enfrentar algums
problemas durante o desenvolvimento com a implementação TopLink, que já é
instalada e previamente configurada no SJSAS 9, isso é especificado no arquivo
persistence.xml através do elemento provider, como pode ser visto no
Quadro 21.
QUADRO 21 - Arquivo de configuração da JPA, persistence.xml.
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistencehttp:
//java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="PU" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<non-jta-data-source>jdbc/Seguranca-WS-DS</non-jta-data-source>
<properties>
<property name="hibernate.dialect"
value="org.hibernate.dialect.PostgreSQLDialect" />
<property name="hibernate.hbm2ddl.auto" value="update" />
<property name="hibernate.show_sql" value="true" />
</properties>
</persistence-unit>
</persistence>
O elemento non-jta-data-source indica qual a fonte de dados
(previamente configurado no servidor de aplicação na seção sobre a configuração do
SJSAS 9, note que aqui o nome da propriedade deve ser o mesmo do JDBC
Resource criado anteriormente) a aplicação irá usar. É através desta fonte de dados
que a JPA irá controlar as transações com o banco de dados.
Por fim, a unidade de persistência da espaço para se configurar algumas
propriedades do provider, através do elemento properties, cada sub-elemento
property representa uma propriedade com o seu nome (atributo name) e valor
(atributo value). Para esta aplicação foram utilizadas duas propriedades:
 hibernate.dialect=org.hibernate.dialect.Postgr
eSQLDialect. Indica qual SGBD é usado pela aplicação, o que
possibilita ao provider utilizar instruções SQL proprietárias do banco
de dados, otimizando assim o desempenho da persistência dos dados.
 hibernate.hbm2ddl.auto=update. Indica que a aplicação
gera e atualiza automaticamente a estrutura do banco de dados.
5.3.3.2 A persistência dos objetos
Para se persistir objetos, deve-se têr-los devidamente configurados com
anotações e, também, ter o arquivo persistence.xml apropriado para a aplicação.
Porém, para que a persistência realmente aconteça deve-se fazer uso da API do JPA
para controlar e manipular os objetos persistidos. Esta lógica está concentrada dentro
das classes que implementam as interfaces dos Web Services. Cada método faz uso de
recursos específicos da JPA para realizar uma tarefa de manipulação de dados, como
por exemplo, consultas, deleções e armazenamento de objetos.
O Quadro 23 apresenta a implementação do Web Service Administrador,
onde pode-se observar a anotação @WebService com dois atributos, um referente a
interface do Web Service, exposta na seção anterior, e outro indicando o nome do
serviço.
Para se fazer uso da JPA dentro de uma classe, é necessário ter uma instância
de um objeto EntityManager, que é obtida através de uma fábrica de
EntityManager (EntityManagerFactory), esta fábrica é criada baseada na
configuração do arquivo persistence.xml.
Cada método implementado da interface realiza uma tarefa distinta, por
exemplo, os métodos deleteXXX excluem do banco de dados, objetos passados para
ele através de um parâmetro, e os métodos saveXXX os salvam. Toda operação de
manipulação de dados necessita de uma transação, para que em caso de falha possa-se
recuperar o estado da base de dados, então, todo método que manipula os dados
começa com uma estrutura de tratamento de exceções try / catch, onde, dentro
dentro
do
bloco
try
inicia-se
uma
transação
(em.getTransaction().begin();) e após a conclusão da tarefa realiza-se a
confirmação do sucesso da operação (em.getTransaction().commit();),
caso alguma exceção for gerada, resultando uma falha na operação, o bloco catch
será
executado
desfazendo
a
tentativa
da
realização
da
operação
(em.getTransaction().rollback();).
Para salvar um objeto na base de dados através da JPA o processo é simples,
apenas utiliza-se o método persiste de uma EntityManager, passando por
parâmetro o objeto que deseja-se salvar. Porém para excluir um objeto o processo é
um pouco mais complexo, deve-se primeiro carregar o objeto que deseja-se excluir,
através do método merge do EntityManager, que irá retorna o objeto carregado
do banco de dados, após isso realizar a invocação do método remove da
EntiryManager passando-o por parâmetro o objeto que deseja-se excluir.
Os métodos recuperarXXX retornam, da base de dados, um objeto que
representa a lista do resultado de uma consulta. Esses métodos utilizam o objeto
Query, que representa uma consulta em uma base de dados, utilizando a linguagem
JPAQL, que é a linguagem específica para manipular objetos persistidos através da
JPA. Foi utilizadas consultas específicas para cada classe, previamente configuradas,
que são referenciadas através do atributo name da anotação @NamedQuery que se
encontra em cada classe persistída.
QUADRO 22 - Implementação do Web Service Administrador.
package net.uniplac.tcc.segurancaws.services;
import java.util.List;
import java.util.logging.Level;
import java.util.logging.Logger;
import
import
import
import
import
javax.jws.WebService;
javax.persistence.EntityManager;
javax.persistence.EntityManagerFactory;
javax.persistence.Persistence;
javax.persistence.Query;
import
import
import
import
net.uniplac.tcc.segurancaws.model.Categoria;
net.uniplac.tcc.segurancaws.model.Cliente;
net.uniplac.tcc.segurancaws.model.OrdemCompra;
net.uniplac.tcc.segurancaws.model.Produto;
@WebService(endpointInterface
"net.uniplac.tcc.segurancaws.services.AdministradorWebServiceIF")
public class AdministradorWebServiceImpl implements AdministradorWebServiceIF {
Logger myLogger = Logger.getLogger(this.getClass().getName());
private EntityManagerFactory emf = Persistence.createEntityManagerFactory("PU");
private EntityManager em;
=
public void deleteCategoria(Categoria categoria) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
Categoria delete = null;
delete = em.merge(categoria);
em.remove(delete);
em.getTransaction().commit();
myLogger.log(Level.INFO,
"Categoria: " + categoria + " foi excluido com sucesso.");
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao excluir categoria:\n" + ex.getMessage());
ex.printStackTrace();
em.getTransaction().rollback();
throw ex;
} finally {
em.close();
}
}
public void deleteCliente(Cliente cliente) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
Cliente delete = null;
delete = em.merge(cliente);
em.remove(delete);
em.getTransaction().commit();
myLogger.log(Level.INFO,
"Cliente: " + cliente + " foi excluido com sucesso.");
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao excluir cliente:\n" + ex.getMessage());
ex.printStackTrace();
em.getTransaction().rollback();
throw ex;
} finally {
em.close();
}
}
public void deleteProduto(Produto produto) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
Produto delete = null;
delete = em.merge(produto);
em.remove(delete);
em.getTransaction().commit();
myLogger.log(Level.INFO,
"Produto: " + produto + " foi excluido com sucesso.");
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao excluir produto:\n" + ex.getMessage());
ex.printStackTrace();
em.getTransaction().rollback();
throw ex;
} finally {
em.close();
}
}
public List<Cliente> recuperarClientes() {
em = emf.createEntityManager();
Query query = em.createNamedQuery("Cliente.findAll");
return query.getResultList();
}
public List<OrdemCompra> recuperarTodasOrdensCompra() {
em = emf.createEntityManager();
Query query = em.createNamedQuery("OrdemCompra.findAll");
return query.getResultList();
}
public List<Categoria> recuperarCategorias() {
em = emf.createEntityManager();
Query query = em.createNamedQuery("Categoria.findAll");
return query.getResultList();
}
public List<Produto> recuperarProdutos() {
em = emf.createEntityManager();
Query query = em.createNamedQuery("Produto.findAll");
return query.getResultList();
}
public void saveCategoria(Categoria categoria) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
em.persist(categoria);
em.getTransaction().commit();
myLogger.log(Level.INFO,
"Categoria: " + categoria + " foi salva com sucesso.");
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao salvar categoria:\n" + ex.getMessage());
ex.printStackTrace();
em.getTransaction().rollback();
throw ex;
} finally {
em.close();
}
}
public void saveCliente(Cliente cliente) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
em.persist(cliente);
em.getTransaction().commit();
myLogger.log(Level.INFO,
"Cliente: " + cliente + " foi salvo com sucesso.");
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao salvar cliente:\n" + ex.getMessage());
ex.printStackTrace();
em.getTransaction().rollback();
throw ex;
} finally {
em.close();
}
}
public void saveProduto(Produto produto) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
em.persist(produto);
em.getTransaction().commit();
myLogger.log(Level.INFO,
"Produto: " + produto + " foi excluido com sucesso.");
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao salvar produto:\n" + ex.getMessage());
ex.printStackTrace();
em.getTransaction().rollback();
throw ex;
} finally {
em.close();
}
}
}
O Quadro 23 apresenta a implementação do Web Service Cliente, onde o
qual se difere do Web Service Administrador (Quadro 22) por apenas dois métodos,
fazerCompra, validarCartaoCredito.
QUADRO 23 - Implementação do Web Service Cliente.
package net.uniplac.tcc.segurancaws.services;
import
import
import
import
java.util.Date;
java.util.List;
java.util.logging.Level;
java.util.logging.Logger;
import
import
import
import
import
javax.jws.WebService;
javax.persistence.EntityManager;
javax.persistence.EntityManagerFactory;
javax.persistence.Persistence;
javax.persistence.Query;
import
import
import
import
import
net.uniplac.tcc.segurancaws.model.Categoria;
net.uniplac.tcc.segurancaws.model.Cliente;
net.uniplac.tcc.segurancaws.model.OrdemCompra;
net.uniplac.tcc.segurancaws.model.Produto;
net.uniplac.tcc.segurancaws.model.ProdutoOrdemCompra;
@WebService(endpointInterface = "net.uniplac.tcc.segurancaws.services.ClienteWebServiceIF")
public class ClienteWebServiceImpl implements ClienteWebServiceIF {
Logger myLogger = Logger.getLogger(this.getClass().getName());
private EntityManagerFactory emf = Persistence.createEntityManagerFactory("PU");
private EntityManager em;
public void fazerCompra(List<ProdutoOrdemCompra> produtos,
Long cartaoCredito, String username) throws Exception {
try {
em = emf.createEntityManager();
em.getTransaction().begin();
myLogger.log(Level.INFO,
"Cliente " + username + " inicio uma ordem de compra.");
if (produtos.size() < 1) {
myLogger.log(Level.SEVERE,
"Lista de produtos invalida.");
throw new IllegalArgumentException(
"Lista de produtos invalida.");
}
if (!(validarCartaoCredito(cartaoCredito.toString()))) {
myLogger.log(Level.SEVERE,
"Cartão de credito do cliente " +
username + " é invalido");
throw new IllegalArgumentException(
"Cartão de credito invalido.");
}
Query query = em.createNamedQuery("Cliente.findByLogin")
.setParameter("login", username);
Cliente cliente = (Cliente) query.getSingleResult();
OrdemCompra ordemCompra = new OrdemCompra();
ordemCompra.setCliente(cliente);
ordemCompra.setDataRealizacao(new Date());
cliente.getOrdensCompra().add(ordemCompra);
ordemCompra.setCartaoCredito(cartaoCredito);
for (ProdutoOrdemCompra produtoOrdemCompra : produtos) {
Produto produto = produtoOrdemCompra.getProduto();
if (produto.getQdtEstoque() <
produtoOrdemCompra.getQtdVendido()){
String mensagem = "Quantidade do produto " +
produto.getNome() + " excedida";
myLogger.log(Level.SEVERE, mensagem);
throw new IllegalArgumentException(mensagem);
}
em.persist(produtoOrdemCompra);
ordemCompra.addProdutoOrdemCompra(produtoOrdemCompra);
}
em.persist(ordemCompra);
myLogger.log(Level.INFO,
"Cliente " + username + " finalizou a ordem de compra.");
em.getTransaction().commit();
} catch (Exception ex) {
myLogger.log(Level.SEVERE,
"Erro ao realizar ordem compra:\n" +
ex.getMessage());
em.getTransaction().rollback();
throw new Exception("Erro ao realizar ordem compra.", ex);
} finally {
em.close();
}
}
public List<Produto> recuperarProdutos() {
em = emf.createEntityManager();
Query query = em.createNamedQuery("Produto.findAll");
return query.getResultList();
}
public List<Categoria> recuperarCategorias() {
em = emf.createEntityManager();
Query query = em.createNamedQuery("Categoria.findAll");
return query.getResultList();
}
public List<OrdemCompra> recuperarOrdensCompra(String login) {
em = emf.createEntityManager();
Query query = em.createNamedQuery("OrdemCompra.findByCliente");
query.setParameter("login", login);
return query.getResultList();
}
private boolean validarCartaoCredito(String cartaoCredito) {
char[] charArray = cartaoCredito.toCharArray();
int[] numero = new int[charArray.length];
int total = 0;
for (int i = 0; i < charArray.length; i++) {
numero[i] = Character.getNumericValue(charArray[i]);
}
for (int i = numero.length - 2; i > -1; i -= 2) {
numero[i] *= 2;
if (numero[i] > 9)
numero[i] -= 9;
}
for (int i = 0; i < numero.length; i++)
total += numero[i];
if (total % 10 != 0)
return false;
return true;
}
}
O método fazerCompra recebe como parâmetro uma lista de
ProdutoOrdemCompra e um número de cartão de crédito. O número de cartão de
crédito é validado através do método validarCartaoCredito (este método não é
exposto no Web Service, pois não faz parte da interface que essa classe implementa).
Ambas as classes de implementação dos Web Services utilizam o recurso de
Logging disponibilizado pela API de Logging do Java SE, cada classe cria um objeto
Logger para realizar as operações de logging. Esse tipo de recurso facilita a tarefa de
desenvolvimento, teste e depuração de uma aplicação, pois pode se monitorar o
comportamento da aplicação através da mensagem de logging, descobrindo assim
possíveis bugs.
5.4 Implementação da segurança
Para se aplicar a segurança na camada de mensagem foi utilizado o
framework XWSS 2.0 que é descrito no segundo capítulo. A camada de segurança é
totalmente independente da lógica do sistema, sendo assim possível ser acoplada com
facilidade na aplicação. Para isso ser possível o servidor de aplicação deve estar
devidamente configurado como foi descrito na seção Instalação e configuração do
ambiente deste capítulo.
O framework XWSS 2.0 necessita de alguns artefatos para seu
funcionamento, que são os arquivos de segurança e as classes tratadoras de segurança
(CallbackHandlers).
5.4.1 Arquivo de segurança
O arquivo de segurança é um documento XML que especifica como é
implementada a segurança na troca de mensagens entre o Web Service e seu cliente.
Deve-se ter um cuidado especial na hora da nomeação deste arquivo, pois o mesmo é
carregado pelo servidor através de seu nome, fazendo assim a ligação do arquivo com
o Web Service especifico. No caso de somente um Web Service na aplicação, o arquivo
pode ser nomeado como server_security_config.xml que o servidor ira
reconhecer que se trata do arquivo de segurança do XWSS 2.0.
Porém, se há mais de um Web Service, os arquivos relativos a cada Web
Service devem ser nomeado conforme a propriedade service, que se encontra no
arquivo sun-jaxws.xml (descrito na seção de arquivos de configuração do
sistema) ou então no atributo serviceName da anotação @WebService da classe
que implementa o serviço.
O
Quadro
24
apresenta
a
codificação
administrador_sercurity_config.xml
referente
do
ws-
arquivo
ao
Web
Service
Administrador que descreve como deve ser aplicada a segurança neste serviço.
QUADRO 24 - Arquivo de segurança do Web Service Administrador.
<?xml version="1.0" encoding="UTF-8"?>
<xwss:JAXRPCSecurity xmlns:xwss="http://java.sun.com/xml/ns/xwss/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/xwss/config xwss.xsd ">
<xwss:Service conformance="bsp">
<xwss:SecurityConFiguration dumpMessages="true">
<xwss:RequireEncryption />
<xwss:RequireUsernameToken passwordDigestRequired="false" />
<xwss:Sign>
<xwss:X509Token certificateAlias="provedor" />
</xwss:Sign>
<xwss:Encrypt>
<xwss:X509Token certificateAlias="consumidor" />
</xwss:Encrypt>
</xwss:SecurityConFiguration>
</xwss:Service>
<xwss:SecurityEnvironmentHandler>
net.uniplac.tcc.segurancaws.services.handlers.AdministradorSecurityHandler
</xwss:SecurityEnvironmentHandler>
</xwss:JAXRPCSecurity>
Pode-se observar que o documento é composto por seu elemento raiz
JAXRPCSecurity que é composto por dois nós, o nó Service e o nó
SecurityEnvironmentHandler.
O nó SecurityEnvironmentHandler contém o nome da classe que
implementa o tratamento da segurança referente aquele Web Service (a classe
CallbackHandler, que será abordada na seção seguinte).
O nó Service é o nó que descreve como que será aplicada as diretrizes de
segurança no Web Service. Neste caso, observando o documento, pode-se dizer que a
mensagem seguirá o seguinte esquema de segurança: toda mensagem recebida deve
ser criptografada (indicado pelo elemento RequireEncryption), seguida de um
username e password (indicado pelo elemento RequireUsernameToken) e toda
mensagem enviada deve ser assinada digitalmente (indicada pelo elemento Sign) e
após deve ser criptografada (indicado pelo elemento Encrypt).
Percebe-se que a ordem dos elementos de Service faz toda a diferença no
esquema de segurança. Por exemplo, para indicar que a mensagem enviada vai ser
assinada digitalmente e depois criptografada, deve-se inserir primeiro o elemento
Sign e depois o elemento Encrypt, e a ordem inversa deve ser obedecida no
consumidor deste serviço, onde o elemento RequireEncryption deve vir
primeiro, e o RequireSignature logo após, isso por que a mensagem foi primeiro
assinada digitalmente e depois criptografada, então, para se obter o conteúdo, primeiro
deve descriptografar a mensagem e depois verificar a assinatura, similar a uma
estrutura de dados pilha.
Para se assinar digitalmente ou criptografar uma mensagem deve-se indicar
qual chave que será usada no processo. As chaves são obtidas através da classe
CallbackHandler, onde é lá que contem a lógica para a realização da tarefa.
Então
cabe
ao
arquivo
descritor
de
segurança
(ws-
administrador_security_config.xml) indicar qual chave deve ser usada e
em qual processo. No caso do Web Service Administrador, é usado a chave pública do
consumidor (cliente do Web Service) para criptografar a mensagem e a chave privada
do provedor (servidor que prove o serviço) para assiná-la digitalmente.
Também é possível, especificar esquema de segurança diferente para cada
método do Web Service, como é visto no Quadro 25 que apresenta o arquivo wscliente_security_config.xml que é o arquivo de configuração de segurança
referente ao Web Service Cliente.
QUADRO 25 - Arquivo de segurança do Web Service Cliente.
<?xml version="1.0" encoding="UTF-8"?>
<xwss:JAXRPCSecurity
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xwss="http://java.sun.com/xml/ns/xwss/config"
xsi:schemaLocation="http://java.sun.com/xml/ns/xwss/config xwss.xsd ">
<xwss:Service conformance="bsp">
<xwss:Port name=
"{http://services.segurancaws.tcc.uniplac.net}ClienteWebServiceImplPort">
<xwss:SecurityConFiguration dumpMessages="true">
<xwss:RequireEncryption />
<xwss:RequireUsernameToken passwordDigestRequired="false" />
<xwss:Sign>
<xwss:X509Token certificateAlias="provedor" />
</xwss:Sign>
<xwss:Encrypt>
<xwss:X509Token certificateAlias="consumidor" />
</xwss:Encrypt>
</xwss:SecurityConFiguration>
<xwss:Operation name=
"{http://services.segurancaws.tcc.uniplac.net}fazer-compra">
<xwss:SecurityConFiguration dumpMessages="true">
<xwss:RequireEncryption />
<xwss:RequireSignature />
<xwss:RequireUsernameToken
passwordDigestRequired="false" />
<xwss:Sign>
<xwss:X509Token certificateAlias="provedor" />
</xwss:Sign>
<xwss:Encrypt>
<xwss:X509Token certificateAlias="consumidor" />
</xwss:Encrypt>
</xwss:SecurityConFiguration>
</xwss:Operation>
</xwss:Port>
<xwss:SecurityEnvironmentHandler>
net.uniplac.tcc.segurancaws.services.handlers.ClienteSecurityHandler
</xwss:SecurityEnvironmentHandler>
</xwss:Service>
<xwss:SecurityEnvironmentHandler>
net.uniplac.tcc.segurancaws.services.handlers.ClienteSecurityHandler
</xwss:SecurityEnvironmentHandler>
</xwss:JAXRPCSecurity>
O elemento Port refere-se a um elemento Port do WSDL do Web Service
(apresentado no capítulo dois). Cada Port possui vários elementos Operation, que
são mapeados pelo JAX-WS a cada método correspondente na classe que implementa
o Web Service, e para cada Operation, ou então para o Port por completo, é
possível especificar um tipo diferente de esquema de segurança. Como pode-se
observar no Quadro 25, o esquema de segurança do Web Service Cliente é similar ao
do Web Service Administrador, exceto pelo método fazerCompra que recebe um
esquema diferente de segurança. Este esquema foi especificado no capítulo quatro no
levantamento de requisitos do sistema, onde, toda ordem de compra realizada por um
cliente deve ser assinada digitalmente por ele para oferecer subsídios futuros para
provar o não-repúdio da operação. Então baseado nessas necessidades especificou-se o
esquema deste método da seguinte forma: a mensagem recebida dese ser uma
mensagem que primeiro foi acrescida de um Username/Password, depois assinada
digitalmente e, por fim, criptografada; e a resposta é primeiramente assinada
digitalmente e após isso criptografada.
Também é possível especificar, através de consultas XPath, o elemento da
mensagem que se deseja aplicar a segurança. Este recurso não foi aplicado ao sistema
desenvolvido devido a falta de necessidade, porém é um recurso válido e que fornece
uma flexibilidade ainda maior na especificação de segurança. Por exemplo, no caso do
método fazerCompra poderia se aplicar a segurança da criptografia somente no
número de cartão de crédito do cliente, tornando-o ilegível para terceiros.
5.4.2 Codificação dos CallbackHandlers
Como descrito na seção anterior, as classes CallbackHandler servem
para tratar elementos de segurança contidos nas mensagens SOAP e são setados nos
arquivos de configuração de segurança dos Web Services e dos clientes do serviço.
A classe que trata esses elementos deve implementar a interface
ClallbackHandler do pacote javax.security.auth.callback, essa
interface especificar um método, que é o handle, o qual deve ser implementado e
que recebe por parâmentro um array de Callback. Um objeto Callback
representa um elemento especifico de segurança:
 PasswordValidationCallback, que trata da validação de
Callbacks Username/Password;
 TimestampValidationCallback, que representa a estampa do
tempo em que a mensagem foi gerada e transmitida;
 SignatureVerificationKeyCallback, que trata da verificação
de uma assinatura digital conforme a base de chaves confiaveis;
 SignatureKeyCallback, que trata da aplicação de uma assinatura
digital;
 DecryptionKeyCallback, que trata da descriptografia de um
elemento criptografado;
 EncryptionKeyCallback, que trata da criptografia de um elemento;
 CertificateValidationCallback, que trata da validação de um
certificado digital;
 PasswordCallback, que trata da configuração do password contido
na mensagem a ser enviada;
 UsernameCallback, que trata da configuração do username da
mensagem a ser enviada.
Todos esses Callbacks são tratados pelas classes CallbackHandler,
ambos do servidor e do cliente (as classes CallbackHandler do servidor tratam
todos os Callbacks exeto o PasswordCallback e o UsernameCallback, em
contra partida, a classe CallbackHandler do cliente trata todos os Callbacks exeto
o PasswordValidationCallback).
Para cada Callback foi criado um método especializado para tratá-lo, cada
método contem uma lógica específica para o seu Callback, fazendo uso de API e
framework de criptografia, certificação e assinatura digital para documentos XML.
Esses trechos de código foram copiados das classes exemplos distribuidas em conjunto
com JWSDP 2.0, essa prática é recomendada pela SUN MICROSYSTEMS (2005h)
devido ao fato de se ter uma implementação testada e com garantia de eficiência e
desempenho.
A implementação do CallbackHandler do cliente do Web Service,
apresentado no Quadro 26, é feita pela classe SecurityCallbackHandler do
pacote net.uniplac.tcc.segurancaws.client.handler do projeto do
cliente. Esta classe segue o o padrão da implementação proposta pela SUN
MICROSYSTEMS (2005h). Porém, com várias modificações na legibilidade do
código e também acrescenta o tratamento dos Callbacks PasswordCallback e
UsernameCallback. Os dados referentes ao Username e Password da aplicação
são extraídos do arquivo de propriedades da aplicação (esse arquivo é apresentado na
seção sobre arquivos de configuração do sistema).
QUADRO 26 - Implementação da classe SecurtyCallbackHandler.
package net.uniplac.tcc.segurancaws.client.handler;
// importações das classes utilizadas...
public
class SecurityCallbackHandler implements CallbackHandler {
private String keyStoreURL;
private String keyStorePassword;
private String keyStoreType;
private String myUsername;
private String myPassword;
private KeyStore keyStore;
private static final String FILE_SEPARATOR = System.getProperty("file.separator");
private static final String FILE_PROPERTIES = "conf" + FILE_SEPARATOR +
"client-security-env.properties";
public SecurityCallbackHandler() throws Exception {
Properties properties = new Properties();
FileInputStream in = new FileInputStream(FILE_PROPERTIES);
properties.load(in);
this.keyStoreURL = properties.getProperty("keystore.url");
this.keyStoreType = properties.getProperty("keystore.type");
this.keyStorePassword = properties.getProperty("keystore.password");
this.myUsername = properties.getProperty("my.username");
this.myPassword = properties.getProperty("my.password");
in.close();
initKeyStore();
}
public void handle(Callback[] callbacks)
throws IOException, UnsupportedCallbackException {
for (int i=0; i < callbacks.length; i++) {
if (callbacks[i] instanceof PasswordCallback) {
passwordCallback(callbacks[i]);
} else if (callbacks[i] instanceof UsernameCallback) {
usernameCallback(callbacks[i]);
} else if (callbacks[i] instanceof TimestampValidationCallback) {
timestampValidationCallback(callbacks[i]);
} else if (callbacks[i] instanceof SignatureVerificationKeyCallback) {
signatureVerificationKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof SignatureKeyCallback) {
signatureKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof DecryptionKeyCallback) {
decryptionKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof EncryptionKeyCallback) {
encryptionKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof CertificateValidationCallback) {
certificateValidationCallback(callbacks[i]);
} else {
throw new UnsupportedCallbackException(null,
"Unsupported Callback Type Encountered");
}
}
}
// implementação dos métodos tratadores dos CallBacks...
}
As implementações dos CallbackHandler dos Web Services são um
pouco mais complexas, comparando-se com a do cliente. A princípio foram
desenvolvidas três classes. Uma classe com a implementação padrão para o tratamento
dos Callbacks de estampa de tempo, criptografia, assinatura digital e certificado
digital. Esta implementação não mudar conforme o Web Service, ela é padronizada
pela SUN MICROSYSTEMS (2005h). Tanto é que a implementação do
CallbackHandler do cliente é muito similar (difere-se apenas pelo trantamento
dos Callbacks Username e Password) em relação ao do servidor. Esta classe então foi
nomeada como DefaultSecurityHandler, descrita no Quadro 27.
QUADRO 27 - Implementação da classe DefaultSecurityHandler.
package net.uniplac.tcc.segurancaws.services.handlers;
// importações das classes utilizadas...
public abstract class DefaultSecurityHandler implements CallbackHandler {
Logger myLogger = Logger.getLogger(this.getClass().getName());
private String keyStoreURL;
private String keyStorePassword;
private String keyStoreType;
private KeyStore keyStore;
public static final String FILE_PROPERTIES = "../server-security-env.properties";
public DefaultSecurityHandler() throws Exception {
myLogger.log(Level.WARNING, "Iniciando properties.");
Properties properties = new Properties();
InputStream in = this.getClass().getClassLoader()
.getResourceAsStream(FILE_PROPERTIES);
properties.load(in);
myLogger.log(Level.WARNING, "Recuperando as propriedades.");
String keyStoreFilePath = properties.getProperty("keystore.file");
this.keyStoreURL = this.getClass().getClassLoader()
.getResource(keyStoreFilePath).getPath();
this.keyStoreType = properties.getProperty("keystore.type");
this.keyStorePassword = properties.getProperty("keystore.password");
in.close();
myLogger.log(Level.WARNING, "Iniciando o keystore.");
initKeyStore();
myLogger.log(Level.WARNING,
"Construtor AdministradorSecurityHandler concluido.");
}
public void handle(Callback[] callbacks)
throws IOException, UnsupportedCallbackException {
for (int i = 0; i < callbacks.length; i++) {
if (callbacks[i] instanceof PasswordValidationCallback) {
myLogger.log(Level.WARNING, "passwordValidationCallback");
passwordValidationCallback(callbacks[i]);
} else if (callbacks[i] instanceof TimestampValidationCallback) {
myLogger.log(Level.WARNING, "timestampValidationCallback");
timestampValidationCallback(callbacks[i]);
} else if (callbacks[i] instanceof SignatureVerificationKeyCallback) {
myLogger.log(Level.WARNING, "signatureVerificationKeyCallback");
signatureVerificationKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof SignatureKeyCallback) {
myLogger.log(Level.WARNING, "signatureKeyCallback");
signatureKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof DecryptionKeyCallback) {
myLogger.log(Level.WARNING, "decryptionKeyCallback");
decryptionKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof EncryptionKeyCallback) {
myLogger.log(Level.WARNING, "encryptionKeyCallback");
encryptionKeyCallback(callbacks[i]);
} else if (callbacks[i] instanceof CertificateValidationCallback) {
myLogger.log(Level.WARNING, "certificateValidationCallback");
certificateValidationCallback(callbacks[i]);
} else {
myLogger.log(Level.WARNING, "Unsupported");
throw new UnsupportedCallbackException(null,
"Unsupported Callback Type Encountered");
}
}
}
// restante da implementação dos metodos Callback
// definição do método abstrato
public abstract void passwordValidationCallback(Callback callback)
throws UnsupportedCallbackException;
// restante da implementação dos metodos Callback
}
O fator que difere a implementação do CallBackHandler do Web
Service Administrador do Web Service Cliente é a validação do CallBack
Password / Username. Cada Web Service deve realizar uma validação diferente
em sua base de dados, uma para o administrador do sistema, e outra para o cliente.
Baseado nessa necessidade é que a classe DefaultSecurityHandler ganho o
modificador abstract na sua definição. O modificador abstract define que é
impossível para classe que o possua criar instâncias de objetos, somente através de
uma sub-classe (herança) é possível instanciar objetos filhos de uma super-classe
abstrata. Porém, é possível especificar que os filhos de uma classe abstrata devão
implementar um ou mais métodos especificados pelo seu pai.
No caso do DefaultSecurityHandler, foi definito o método
passwordValidationCallback como abstrato. Sendo assim, toda classe que
herdar de DefaultSecurityHandler deve implementar esse método que é
específico para validação de usuários através dos Callbacks
Username e
Password.
Então, com base na classe DefaultSecurityHandler, foram criadas
duas
classes
especificas
para
cada
Web
Service,
AdministradorSecurityHandler para o Web Service Administrador e
ClienteSecurityHandler para o Web Service Cliente. Esta abordagem foi
escolhida devido ao fato da enorme repetição de código em ambas as classes caso não
existisse uma classe pai, sendo assim, a classe pai realiza o trabalho em comum entre
as duas classes, deixando espaço para a especialização da validação de usuários de
cada classe filho.
Como descrito acima, cada classe filho de DefaultCallbackHandler
necessita implementar o método passwordValidationCallback. No Quadro
28 é apresentando a classe AdministradorSecurityHanler que especializa a
classe DefaultCallbackHandler para a validação do usuário administrador.
QUADRO 28 - Implementação da classe AdministradorSecurityHanler.
package net.uniplac.tcc.segurancaws.services.handlers;
import
import
import
import
java.io.InputStream;
java.util.Properties;
java.util.logging.Level;
java.util.logging.Logger;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.UnsupportedCallbackException;
import com.sun.xml.wss.impl.callback.PasswordValidationCallback;
public class AdministradorSecurityHandler extends DefaultSecurityHandler {
private String admLogin;
private String admPassword;
private Logger myLogger = Logger.getLogger(this.getClass().getName());
public AdministradorSecurityHandler() throws Exception {
super();
Properties properties = new Properties();
InputStream in = this.getClass().getClassLoader()
.getResourceAsStream(FILE_PROPERTIES);
properties.load(in);
this.admLogin = properties.getProperty("adm.login");
this.admPassword = properties.getProperty("adm.password");
myLogger.log(Level.INFO, "Dados do administrador caregados com sucesso.");
in.close();
}
public void passwordValidationCallback(Callback callback)
throws UnsupportedCallbackException {
PasswordValidationCallback cb = (PasswordValidationCallback) callback;
if (cb.getRequest() instanceof
PasswordValidationCallback.PlainTextPasswordRequest) {
cb.setValidator(new PlainTextPasswordValidator());
myLogger.log(Level.INFO, "Administrador logado com sucesso.");
} else {
myLogger.log(Level.WARNING,
"Falha na autentificação do administrador.");
throw new UnsupportedCallbackException(null,
"Unsupported Password Validation Callback Type Encountered");
}
}
private class PlainTextPasswordValidator
implements PasswordValidationCallback.PasswordValidator {
public boolean validate(PasswordValidationCallback.Request request)
throws PasswordValidationCallback.PasswordValidationException {
String username = null;
String password = null;
if (request instanceof
PasswordValidationCallback.PlainTextPasswordRequest) {
PasswordValidationCallback.PlainTextPasswordRequest
plainTextCallback =
(PasswordValidationCallback.PlainTextPasswordRequest) request;
username = plainTextCallback.getUsername();
password = plainTextCallback.getPassword();
if (admLogin.equals(username) && admPassword.equals(password))
return true;
}
return false;
}
}
}
No construtor da classe AdministradorSecurityHanler é obtido o
username e o password do administrador do sistema, logo após é implementado o
método abstrato da classe pai. Para se validar um username / password o framework
XWSS 2.0 exige que o desenvolvedor crie uma classe que implemente a interface
interna
PasswordValidator
contida
dentro
da
classe
PasswordValidationCallback. Esta interface define um método validate
que tem como contrato retornar um valor boleano, verdadeiro se o usuário é valido,
falso caso não seja.
Com base nisso é comparado o username / password da requisição com o
valor contido no arquivo de propriedade, e definido assim se o administrador passou
ou não os argumentos corretos. Caso verdadeiro a sua operação é autorizada, caso
contrário é retornado uma mensagem contendo um <SOAP-FAULT> indicando que o
usuário não é válido para realizar tal operação.
O que difere a classe AdministradorSecurityHanler da classe
ClienteSecurityHandler, apresentada no Quadro 29, é a lógica de validação
do usuário. Na classe ClienteSecurityHandler o usuário é validade conforme
a base de dados da aplicação. Através do login e pela JPA é obtido o cliente, e assim é
feita a validação comparando com os argumentos passados pela requisição
(Callback Username / Password).
QUADRO 29 - Implementação da classe ClienteSecurityHandler.
package net.uniplac.tcc.segurancaws.services.handlers;
import java.util.logging.Level;
import java.util.logging.Logger;
import
import
import
import
import
javax.persistence.EntityManager;
javax.persistence.PersistenceContext;
javax.persistence.Query;
javax.security.auth.callback.Callback;
javax.security.auth.callback.UnsupportedCallbackException;
import net.uniplac.tcc.segurancaws.model.Cliente;
import com.sun.xml.wss.impl.callback.PasswordValidationCallback;
public class ClienteSecurityHandler extends DefaultSecurityHandler {
@PersistenceContext(name = "PU")
private EntityManager em;
private Logger myLogger = Logger.getLogger(this.getClass().getName());
public ClienteSecurityHandler() throws Exception {
super();
}
public void passwordValidationCallback(Callback callback)
throws UnsupportedCallbackException {
PasswordValidationCallback cb = (PasswordValidationCallback) callback;
if (cb.getRequest() instanceof PasswordValidationCallback.PlainTextPasswordRequest) {
PasswordValidationCallback.PlainTextPasswordRequest
request = (PasswordValidationCallback.PlainTextPasswordRequest)
cb.getRequest();
cb.setValidator(new PlainTextPasswordValidator());
myLogger.log(Level.INFO, "Cliente " + request.getUsername() +
" autenticado com sucesso.");
} else {
myLogger.log(Level.WARNING, "Falha na autentificação do cliente.");
throw new UnsupportedCallbackException(null,
"Unsupported Password Validation Callback Type Encountered");
}
}
private class PlainTextPasswordValidator
implements PasswordValidationCallback.PasswordValidator {
public boolean validate(PasswordValidationCallback.Request request)
throws PasswordValidationCallback.PasswordValidationException {
String username = null;
String password = null;
Cliente cliente = null;
if (request instanceof
PasswordValidationCallback.PlainTextPasswordRequest) {
PasswordValidationCallback.PlainTextPasswordRequest
plainTextCallback =
(PasswordValidationCallback.PlainTextPasswordRequest) request;
username = plainTextCallback.getUsername();
password = plainTextCallback.getPassword();
try {
Query query = em.createNamedQuery("Cliente.findByLogin")
.setParameter("login", username);
cliente = (Cliente) query.getSingleResult();
if (cliente != null &&
cliente.getPassword().equals(password)) {
return true;
} else {
return false;
}
} catch (Exception ex) {
ex.printStackTrace();
return false;
}
}
return false;
}
}
}
5.5 Arquivos de configuração do sistema
Os sistemas, tanto servidor como cliente, são compostos, além do código
fonte, por uma série de arquivos de configurações e bibliotecas necessárias para a sua
execução. Nesta seção será explanado cada um destes arquivos, sua codificação e
funcionalidade.
O que ambos os sistemas tem em comum é somente as bibliotecas (arquivos
de extensão .jar), que contém as APIs necessárias para codificação e execução do
sistema, até então citadas anteriormente no trabalho. Esses arquivos são: appservrt.jar, appserv-ws.jar, activation.jar e javaee.jar. Todos
esses arquivos podem ser encontrados dentro do diretório lib da instalação do
servidor SJSAS 9.
5.5.1 Arquivos do servidor
 provedor.jks: o arquivo provedor.jks é onde está armazenado as
chaves e certificados digitais do servidor do Web Services. Este arquivo foi
construído pela ferramenta keytool que acompanha a ditribuição do JDK
5. Estes arquivos contem, o par de chave pública e privada do servidor, com
o nome de provedor e, também, contém o certificado digital do cliente, com
nome de consumidor. Este trabalho de importar e exportar certificados
digitais através dos arquivos de armazenamento de chaves assimétricas foi
realizado pela ferramenta keytool.
 sun-jaxws.xml: o arquivo sun-jaxws.xml é o descritor do conjunto
de Web Services contidos dentro da aplicação, é nele que se específica o
nome do Web Service, interface do Web Service e a classe que implementa,
o name space do Web Service e a URL de acesso ao serviço.
 web.xml: web.xml é o arquivo descritor de todas as aplicações Web para
plataforma Java EE, no caso desta aplicação, é neste arquivo que se indica a
classe servelt da API do JAX-WS que fará o tratamento das requisições
HTTP aos serviços.
 server-security-env.properties: este arquivo foi criado devido
a necessidade de externalizar alguns parâmetro de configuração da
aplicação, ele não faz parte de nenhuma API ou framework, é carregado
manualmente pela aplicação. Este arquivo de propriedades contém, o
endereço relativo do arquivo de chaves assimétricas e certificados digitais,
também contém a senha necessária para o acesso dos dados do arquivo de
chaves, e também contem o login e password do administrador do sistema,
eliminando a necessidade do armazenamento do mesmo em uma base de
dados.
 build.xml: o arquivo build.xml é o arquivo usando pela Ant, que
tem como propósito automação de tarefas para construção de aplicações,
tarefas como, empacotar, criar diretórios base, fazer limpeza de artefatos
desnecessários, compilar código fonte e também, no caso de uma aplicação
que faça uso do JAX-WS, gerar classes e artefatos necessários para a
construção do Web Service.
5.5.2 Arquivos do cliente
 client-security-env.properties: este arquivo é similar ao
arquivo de propriedades que se encontra no projeto do servidor, porém a
diferença é que este armazena o login / password do cliente no sistema,
esses dados serão enviados por cada requisição para serem autenticados no
servidor do Web Service;
 consumidor.jks: este arquivo é similar ao arquivo de chaves de
criptografia assimétrica encontrado no projeto do servidor, porém aqui é que
se armazena o par de chaves do cliente (consumidor);
 MANIFEST.MF: esse arquivo é o descritor do arquivo de distribuição da
aplicação cliente, nele é necessário indicar qual é classe principal (que
possui o método main) e as bibliotecas necessárias para a execução da
aplicação, como pode ser visto no Quadro 30:
QUADRO 30 - Arquivo MANIFEST.MF do projeto Cliente.
Manifest-Version: 1.0
Main-Class: net.uniplac.tcc.segurancaws.client.main.Main
Created-By: Fernando Luiz Parisotto
Class-Path: lib\appserv-rt.jar lib\appserv-ws.jar lib\j2ee.jar
lib\javaee.jar lib\tinylaf.jar
 ws-administrador_security_config.xml
e
ws-
cliente_security_config.xml: estes arquivos já foram discutidos
na seção sobre arquivos de segurança deste capítulo.
 bindings-administrador.xml
e
bindings-cliente.xml:
ambos arquivos são usados na geração dos artefatos dos clientes do Web
Services, nesses arquivos é possível customizar estes artefatos gerados. Foi
utilizado pelo trabalho o recurso de clientes assíncronos do JAX-WS, que é
descrito
através
do
<enableAsyncMapping>true</enableAsyncMapping>
elemento
nos
arquivos bindings.
5.6 Desenvolvimento do cliente Web Service
Com intuito de demonstração do ambiente proposto pelo trabalho, foi
desenvolvido um cliente para os Web Services expostos nas seções anteriores. O
cliente foi desenvolvido utilizando a plataforma Java SE, e a sua interface gráfica foi
desenvolvida com Toolkit Swing, em conjunto com as demais APIs de Web Services
do Java EE e de segurança do XWSS 2.0.
O software cliente segue o contrato dos Web Services, que foram abordados
no capítulo de modelagem. O sistema cliente é constituído basicamente pelos artefatos
gerados pela ferramenta de importação de Web Services do JAX-WS (wsimport), pelas
classes responsáveis pela GUI (Graphical user interface), pela classe responsável pelo
tratamento da segurança (semelhante as classes CallbackHandler abordadas nas
seções de segurança do servidor) e pelos arquivos de configuração (abordados na
seção anterior).
O cliente apresenta a interface inicial (Figura 13) que faz a distinção entre o
usuário Administrador e o usuário Cliente, através de um diálogo de login do sistema.
A interface é subdividida em abas, cada uma com seu devido assunto: produtos,
clientes, ordens de compra e carrinho de compra. Cada aba apresenta as operações
possíveis para o usuário, referente ao assunto da aba, e também, logo abaixo se tem
uma tabela com os dados do sistema para o assunto.
FIGURA 13 - Imagem da janela principal do sistema.
Na aba produto, o Cliente apenas poderá adicionar o produto no seu carrinho
de compras ou então recuperar os produtos do sistema. Já o Administrador poderá
efetuar operações cadastrais sobre as Categorias e os Produtos, também podendo
recuperá-los do estoque. Como o Administrador é encapas de efetuar uma Ordem de
Compra, o mesmo não poderá adicionar um produto ao carrinho de compras.
Na aba de Clientes (acessível somente para o Administrador) é possível
efetuar operações cadastrais sobre os Clientes, também como ver os dados contidos no
sistema referentes a essa entidade.
Na aba Ordem Compra, da qual tanto o Administrador e o Cliente têm
acessos, ambos podem recuperar Ordens de Compra (o cliente somente as suas) e ver
seus detalhes (listas de produtos).
Finalmente é através da aba Carrinho de Compra que os Clientes realizam
suas Ordens de Compra. Como o próprio nome da aba já diz, a aba carrinho de compra
representa uma espécie de cesta de compra, onde o cliente armazena os Produtos
selecionados no catálogo em conjunto com a quantidade que este deseja comprar e
através do botão Fazer Compra que será realizada a Ordem de Compra, porém
antes é perguntado (através de um dialogo de entrada de dados) para o Cliente o seu
número de cartão de credito.
5.7 Demonstração do ambiente
Para se verificar os resultados esperados é necessário ter acesso as
mensagens trocadas entre o cliente e o servidor, esses dados são obtidos através do
recurso de log disponibilizado pelo XWSS 2.0, este recurso é habilitado no arquivo de
configuração de segurança do Web Service, tanto no cliente como no servidor, pelo
atributo dumpMessages do elemento SecurityConFiguration. No cliente
será mostrado as mensagens no console default do sistema, no servidor será escrito nos
arquivos de log.
Para demonstração da segurança foi escolhida a operação fazer compra do
Web Service cliente, devido a sua maior complexidade relativa aos outras operações e
também por envolver dados supostamente críticos, como o número de cartão de
credito do cliente.
5.7.1 Web Service não seguro
O Quadro 31 demonstra uma troca de mensagem entre o cliente e o servidor
sem nenhum esquema de segurança, neste momento, foi desabilitado as políticas de
segurança do servidor e do cliente, para que isso fosse possível foi apenas comentado
o conteúdo do elemento SecurityConFiguration nos arquivos referentes a
segurança do servidor e do cliente.
QUADRO 31 - Quadro demonstrando a troca de mensagens não seguras.
<!—Inicio da mensagem de requisição-->
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header />
<SOAP-ENV:Body>
<ns2:fazer-compra
xmlns:ns2="http://services.segurancaws.tcc.uniplac.net">
<produtos>
<precoTotal>0.0</precoTotal>
<produto>
<categoria>
<id>1</id>
<nome>Tábua</nome>
<unidade>Métros quadrados</unidade>
</categoria>
<id>1</id>
<nome>Pínus</nome>
<precoUnitario>100.0</precoUnitario>
<qdtEstoque>500</qdtEstoque>
</produto>
<qtdVendido>5</qtdVendido>
</produtos>
<cartaoCredito>5215220180348249</cartaoCredito>
<username>fernando</username>
</ns2:fazer-compra>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<!—Fim da mensagem de requisição -->
<!—Inicio da mensagem de resposta -->
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header />
<SOAP-ENV:Body>
<ns2:fazer-compraResponse
xmlns:ns2="http://services.segurancaws.tcc.uniplac.net" />
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<!—Fim da mensagem de resposta -->
Como se pôde observar no Quadro 31, a mensagem não está criptografada ou
assinada digitalmente, pois os dados estão legíveis e nenhum elemento XML espefíco
de segurança foi adicionado ao documento. Se um intermediário da rede entre o cliente
e o servidor estivesse executando um software de captura de pacotes TCP/IP seria
capaz de recuperar todos os pacotes da mensagem trocada, montá-los e obter de forma
indevida as informações trocadas, sem o conhecimento e autorização das partes
interessadas (cliente e servidor).
Também à outro fator agravante, neste cenário não há como se autenticar o
usuario através da mensagem do cliente que requesita o serviço, devido a ausência dos
Tokens de Username e Password, porém, pode-se utilizar mecanismos de autenticação
do protocolo HTTP, também como criptografia sobre o mesmo através de uma
conexão SSL, sendo assim a mensagem estaria segura através da camada de transporte.
5.7.2 Web service seguro
O Quadro 32 apresenta um cenário oposto ao Quadro 31, no qual também há
a troca de mensagens entre o cliente e o servidor. Porém, neste caso a mensagem está
segura, pois foram aplicadas as políticas de segurança especificadas nos arquivos de
segurança (apenas foi descomentado o que havia sido comentado no documento de
segurança). Foi realizada uma chamada a operação fazer compra com os mesmos
dados contidos no Quadro 31.
QUADRO 32 - Quadro demonstrando a troca de mensagens seguras.
1
2
3
4
5
6
7
8
9
0
11
12
13
14
15
16
17
18
19
10
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
<?xml version="1.0" encoding="UTF-8"?>
<!-14/11/2006 15:21:20 com.sun.xml.wss.impl.filter.DumpFilter process
INFO: ==== Sending Message Start ====
-->
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<wsse:Security
xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
SOAP-ENV:mustUnderstand="1">
<wsse:BinarySecurityToken
xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
EncodingType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary"
ValueType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="XWSSGID-11635284804211099240129">
MIICzjCCAjegAwIBAgIBAjANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEMMAoGA1
UECBMDU0NBMQwwCgYDVQQKEwNTVU4xHjAcBgNVBAMTFWNlcnRpZmljYXRlLWF1dGhvcml0
eTAeFw0wNjAzMTkxMzU0NDJaFw0xNjAzMTYxMzU0NDJaMDgxCzAJBgNVBAYTAlVTMQwwCg
YDVQQIEwNTQ0ExDDAKBgNVBAoTA1NVTjENMAsGA1UEAxMEczFhczCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEArDBq4mMrOm4FFVQLvITQu9ryluc0gQdrxYgCI3dvKk5Uo2Jq8l
Vh5iz331o7RvJlHORS1YYfNHTthWwSCD3goYa6/Xlt7rprHRNzUPpotAdBcXq0shiWpNSm
Hxqkx28kPCnjuF3sz/Pq8GQNKwWJKXnl1ZzT387Csjmngf/FuzECAwEAAaOB1jCB0zAJBg
NVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0
ZTAdBgNVHQ4EFgQUeN9famBBWzHNUIwWRhMPktcM+VQweQYDVR0jBHIwcIAUdry1wGRZ2f
yJSKisVSxpMEmIiaahTaRLMEkxCzAJBgNVBAYTAlVTMQwwCgYDVQQIEwNTQ0ExDDAKBgNV
BAoTA1NVTjEeMBwGA1UEAxMVY2VydGlmaWNhdGUtYXV0aG9yaXR5ggkA4HaEvd6hq8YwDQ
YJKoZIhvcNAQEEBQADgYEAmUnJqyL43x6Rh4zWE7bi16fMcy71YGmvAIi4E3CRVdeiCFpO
ABco220RDxo46rqQJrM3q9ntZZZUcAugWUD//67n++liII2DFK4+poJP+L19+7m4R1OmHp
kpkRO6G8zXUvpSAoai45rzQSRSu0TN8s11IIJQQxiIkVcyJaMoU0w=
</wsse:BinarySecurityToken>
<xenc:EncryptedKey
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference>
<wsse:Reference
URI="#XWSSGID-11635284804211099240129"
ValueType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
UqbuRuPfNzcR9FV1EjpzfXFf1S4+8bO+5natxSj9mASaFCGblsm6Zq4A5nU02Uz3vWgLx6
MCJbp+qJJ3ji54H8baoul7donSwnw86hGEsLQ48WELr7EdSg91Mh6rvuJedg10eQTYBvg/
i9kssjydBaKcMXpUn0khp9wLVS77oPU=
</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference
URI="#XWSSGID-1163528480500-1719840684" />
</xenc:ReferenceList>
</xenc:EncryptedKey>
<wsse:BinarySecurityToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsd"
EncodingType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile1.0#X509v3"
wsu:Id="XWSSGID-1163528480421-714906389">
MIIC3TCCAkagAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEMMAoGA1
UECBMDU0NBMQwwCgYDVQQKEwNTVU4xHjAcBgNVBAMTFWNlcnRpZmljYXRlLWF1dGhvcml0
eTAeFw0wNjAzMTkxMzQ5MDJaFw0xNjAzMTYxMzQ5MDJaMEcxCzAJBgNVBAYTAlVTMQwwCg
YDVQQIEwNTQ0ExDDAKBgNVBAoTA1NVTjEcMBoGA1UEAxMTeHdzLXNlY3VyaXR5LWNsaWVu
dDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzNDPKUz1MhUH1LsrLqXKxciOKSWeTr
doe/SVwe/4uy5eobAWSsSTposaOYFyuxf3cGCCIs7u0jMAXLQ9jzobDbt9XQ4tXPoBzKKz
S+yU6hDk2TcOCkioeT9A9db5LF8yevhwXKB4AJ1Eh//Dp/djoonXCCxsxupQZp3ueRJrR9
8CAwEAAaOB1jCB0zAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVy
YXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUECH05VC3/WGWH4AGD6tnH0h+kFUweQYDVR
0jBHIwcIAUdry1wGRZ2fyJSKisVSxpMEmIiaahTaRLMEkxCzAJBgNVBAYTAlVTMQwwCgYD
VQQIEwNTQ0ExDDAKBgNVBAoTA1NVTjEeMBwGA1UEAxMVY2VydGlmaWNhdGUtYXV0aG9yaX
R5ggkA4HaEvd6hq8YwDQYJKoZIhvcNAQEEBQADgYEA0RhOk67pCrO6MgZZGqrmAMW676fZ
owBxTKlFq88nrf8v1MUxV8H9wgbTDrwR0HtxY3TGpDFw2tNAww2pyDX/pQ2Wt46ichluGx
jfaEV53loKTOM7syAmlicWqViGzBfgzriIl918TzFaX9BD/Y55bKZQk057maBCSkUuFfF4
53s=
</wsse:BinarySecurityToken>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="wsse SOAP-ENV" />
</ds:CanonicalizationMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference
URI="#XWSSGID-11635284804531616368774">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>
44fPX8/ouOEEJFgIDwwfU2AUn4g=
</ds:DigestValue>
</ds:Reference>
<ds:Reference
URI="#XWSSGID-1163528480453-1107127414">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>
c7MEy8QfyxFudz6ORrAweSTTSqg=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
vowC5KZx6Sa6+cDT6XvnN9DjDwxvNTv7w2jDIkei6qcTeCZ+KCXtYxDZeF867JY+KLA9NA
b3cAbniQm3UH8BFKCueVwu9iIJm7lqP4wgQgB0ubCNwUKVw86zeB4brH5dgO0ZvY1HURdW
Lmyu624P6zsJP5K7jtlAWaCuEIlcSH8=
</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsd"
wsu:Id="XWSSGID-1163528480437750240271">
<wsse:Reference
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
URI="#XWSSGID-1163528480421-714906389"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile1.0#X509v3" />
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsd"
wsu:Id="XWSSGID-1163528480453-1107127414">
<wsu:Created>2006-11-14T18:21:20Z</wsu:Created>
<wsu:Expires>2006-11-14T18:21:25Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsd"
wsu:Id="XWSSGID-1163528480421-1351393566">
<wsse:Username>fernando</wsse:Username>
<wsse:Password Type=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile1.0#PasswordText">
****
</wsse:Password>
<wsse:Nonce EncodingType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary">
INvSjLxkOXPDLyGRCw0lblyv
</wsse:Nonce>
<wsu:Created>2006-11-14T18:21:20Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsd"
wsu:Id="XWSSGID-11635284804531616368774">
<xenc:EncryptedData
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="XWSSGID-1163528480500-1719840684"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<xenc:CipherData>
<xenc:CipherValue>
/xbypE9YC5ZnoDGYIzHIu8z0qQuwF6vvYKAq4rEIiaRzraBd+WEoCTNiD6tInxyqQvJGTs
GINrgdxx2dSTBtETAUxfBnTFwqHf4gyHyiA+cdK4FrEBRHZ49N+dQ4GwyPTATHu7IeuCzm
Yng3pS2J8gpUdsHCp0kmnidBnlwrEZ+9LYHV0XUdysd4kZfigKyVUEJ0Xn+5zzpcwU9OtW
D5Q1Huujh12bissg5EY7U1FbBb6iLE7ARjU9odR5wC7aKzd4YZFZjd+6HI2TXrh14TpeE8
ea/KyyYuqbd6HZIKbKcr93A6kzDKLPqZEfg7zlmxcZMZco/jJ387bouIyILvqG9f3zM5a0
6wTV3U3BRDtJOpv+j/ClBJWgRKW8i9ic7SuoPuh0ah+W/91wh2vIpAHNx7bhgoMTmvKgpL
yUigEWgjZZ9oaLjM76j7dlvJPNgfUFLM7fey4fhCuKtf+55v6hBKOOfgA4i++DK7+3F5c0
CPJA+sReb+oK9jAyhn7DOtVejNhQKIYCmRMpkH0YQJVLC3ZvXkMj8ZrUXrHhpPRySfymth
JI4nZHaWcFfkCtTJUZ2A8YJYNTUVaLvI/fqiDNjrDfavYpuZSns7xw5AoCU9+i1IQzaGgT
4ALuP3rkUhxZiFiSRfnmM+ZchD5VkcTypgFYc0fNhP1KuuKtFhDTKW64ECrgcGoNnGTPpa
WpgdBv3BzJFgO7pHHcIA7X1XfTli8UHu19HTTIpYnSNayvewvbEgSfoeSEW3trsl+jjK
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<!-- Sending Message End -->
Devido a extensão do documento gerado foi apenas apresentada a mensagem
de requisição ao Web Service. Pode-se perceber que a mensagem segura faz uso do
SOAP-HEADER para armazenar os Tokens de segurança. Como foi especificado no
arquivo de segurança do servidor, a mensagem de requisição a operação fazer compra
deve conter o Username / Password (linha 141 até 150 do Quadro 32), a assinatura
digital do Cliente que está requisitando o serviço (linha 89 até 133 do Quadro 32) e o
conteúdo da mensagem (SOAP-BODY) deve estar criptografado, como pode ser
observado na linha 164 até 185 do Quadro 32.
5.8 Conclusão
Neste capítulo foram apresentados os softwares que compõem o ambiente do
sistema proposto no capítulo anterior. Também foram apresentadas as suas devidas
configurações. Em seguida foi apresentada a implementação do sistema e logo a
aplicação e configuração da segurança nos Web Services. Com o serviço
implementado, foi desenvolvido um cliente para o mesmo e, assim, demonstrada a
diferenciação do ambiente seguro e o não seguro.
Neste capítulo que se alcançaram os objetivos propostos pelo trabalho, que
eram os de desenvolver um Web Service utilizando os recursos de segurança
apresentados pelo estudo realizado e de demonstrar a integração dos clientes com o
serviço implementado em um ambiente seguro.
No decorrer do desenvolvimento foram enfrentadas diversas dificuldades, de
origem de configuração do ambiente e de origem de codificação do sistema.
Os problemas enfrentados na configuração do ambiente referiam-se na
configuração correta do servidor de aplicação, pelo qual o mesmo deveria conter em
seu diretório lib os arquivos de biblioteca do XWSS 2.0. A configuração correta foi
obtida através da lista de discussão do projeto XWSS 2.0 hospedo pelo portal java.net.
Já os problemas na codificação foram mais amplos, primeiramente, se
descobriu, através de teste, que a especificação servlet 2.5 (atual especificação do Java
EE 5) não é compatível com XWSS 2.0. Essa informação também foi obtida através da
lista de discução do XWSS 2.0. Devido ao fato de não se poder utilizar um projeto
com a especificação mais recente, também não se poderia utilizar os recursos mais
recentes, tais como, injeção de dependências, utilizadas para fornecer à aplicação as
EntityManager e, também, o recurso transacional do Java EE 5, o JTA. Sendo assim,
ficou a cabo da aplicação fazer o controle transacional e obter os objetos
EntityMananger para a persistência dos objetos.
Outro problema enfrentado foi a definição dos nomes dos arquivos de
segurança do XWSS 2.0, que devem condizer exatamente com o nome do elemento
service-name do WSDL do Web Serivce, ou com o atributo de mesmo nome da
anotação @WebService.
Também se enfrentou dificuldade com a implementação JPA padrão do
servidor de aplicação SJSAS 9.0, o TopLink. Por isso, foi utilizado uma
implementação externa do servidor, o Hibernate.
Finalmente, o último problema enfrentado foi o dos arquivos serversecurity-env.properties e provedor.jks. Ambos arquivos precisavam
ser referenciados dentro da aplicação, pois a classe DefaultSecurityHandler
precisava das informações contidas nesses arquivos. O método utilizado para se obter
uma referência desses arquivos foi obtido através de usuarios do forum do Grupo de
Ususarios Java (www.guj.com.br). A solução proposta se encontra descrita no
capítulo.
6 CONSIDERAÇÕES FINAIS
O trabalho teve como objetivo principal apresentar métodos e tecnologias de
segurança aplicáveis em Web Services. Este objetivo foi dividido em uma série de
objetivos específicos.
O primeiro objetivo específico do trabalho era apresentar os principais
padrões e especificações envolvidas na tecnologia Web Services, que foi atingido no
decorrer do desenvolvimento do capítulo 2. Este referencial teórico é de essencial
importância para o trabalho, devido ao fato que se deve ter conhecimento de SOAP e
WSDL para se aplicar segurança em um Web Service. Nesta etapa do trabalho não
foram enfrentadas dificuldades, pelo fato de se existirem boas referencias
bibliográficas sobre o assunto, como está especificado na seção de referências
bibliográficas.
O segundo objetivo específico deste trabalho trata de levantar os principais
recursos para aplicação de segurança em Web Services, que foi alcançado no decorer
do desenvolvimento do terceiro capítulo. Com a realização deste estudo se apresentou
os dois conceitos de segurança em Web Services, a segurança sobre a mensagem e a
segurança sobre a camada de transporte, cada uma com suas vantagens e desvantagens.
Por ser um assunto relativamente recente, se teve dificuldade de obter referencial
bibliográfico em Língua Portuguesa neste capítulo.
Um dos principais problemas encontrados no trabalho era de escolher qual
método de segurança que deveria ser utilizado. Através da análise dos resultados da
pesquisa se optou pela utilização da segurança sobre a mensagem, pois essa tecnologia
foi desenvolvida especialmente para Web Services, diferente da técnica de segurança
sobre a camada de transporte, que é mais genérica e serve também para aplicações
Web que não fazem uso de Web Services. A segurança na camada da mensagem
apresenta uma maior flexibilidade de regras de segurança, garantindo a segurança de
fim-a-fim e por ser uma tecnologia recente e com pouco referencial teórico
(principalmente em Língua Portuguesa) optou-se por desenvolver o trabalho com essa
tecnologia.
O terceiro e quarto objetivos foram atingindos no capítulo cinco, que
visavam desenvolver um Web Service seguro e apresenta-lo em um ambiente que
permitisse monitora-lo. Porém, anteriormente no capítulo quatro, foi apresentado um
estudo de caso referente ao sistema a ser desenvolvido, servindo de base para se
aplicar a tecnologia em um sistema que simulasse um ambiente real com as suas
necessidade de segurança.
Seguindo a especificação do quarto capítulo, o sistema foi desenvolvido e o
ambiente a que ele reside foi configurado. Nestas etapas foram enfrentadas
dificuldades técnicas, tanto de configuração do ambiente como também de
desenvolvimento, e essas dificuldade foram superadas através de pesquisa e ajuda de
listas de discussões e fóruns especializados na tecnologia.
A realização deste trabalho foi gratificante devido ao fato de se ter alcançado
com sucesso todos os objetivos propostos e também de se ter apresentado um
referencial teórico e prático para a aplicação de segurança em Web Services.
Após o termino da pesquisa e desenvolvimento, concluiu-se que, realmente é
necessária uma tecnológica especial que trate de segurança em Web Services. Devido
ao fato de os Web Services servirem de base para uma serie de novas tecnologias e
paradigmas de sistemas distribuídos (SOA, ESB – Enterprise Service Bus), onde todos
esses necessitam de uma especificação de segurança, que na maioria dos casos,
tecnologias existentes não suprem a necessidade.
Também se analisou o custo - beneficio oferecido pela tecnologia, onde a
tecnologia apresentou um fator positivo neste quesito, e também ficou claro que pra se
aplicar uma camada de segurança em aplicações que façam uso de Web Services é
necessário optar por tecnologias que não prejudiquem os benefícios oferecidos pela
arquitetura, como por exemplo, interoperabilidade. Se observou também que há uma
demanda maior por recursos de processamento, devido ao fato de que toda a
mensagem deve passar por uma verificação de segurança, e isso acaba consumindo
recursos custosos de processamento. Mas, em contra partida, tem-se a garantia de se
utilizar uma segurança que se integra a tecnologia, não prejudicando a
interoperabilidade que a arquitetura Web Services prezam em conservar.
A tecnologia de Web Services está se tornando base para um novo paradigma
de desenvolvimento de sistemas orientados a serviços (SOA, Service-Oriented
Architecture), do qual a segurança sobre a mensagem é de extrema relevância. Nesta
nova classe de sistemas a mensagem trafega entre uma série de intermediários, cada
um desses agregando ou transformando informações até chegar ao ponto final
totalmente processada. Por isso, que a mensagem segura é necessária, pois nesse novo
paradigma não se tem total conhecimento de quais serviços processaram a mensagem e
nem por qual caminho que a mesagem percorrerá para ser processada.
Para sugestão a trabalhos futuros seria de desenvolver um ambiente usando a
arquitetura SOA em conjunto com a nova especificação de segurança WSIT (Web
Services Interoperability Technologies) que abrange otimização no transporte da
mensagem, melhor gestão de erros, transações atômicas, melhor gestão de segurança e
total garantia de interoperabilidade com a plataforma .Net da Microsoft. A tecnologia
WSIT é a nova geração de tecnologias de segurança e interoperabilidade para os Web
Services. Uma das propostas principais dessa nova versão de tecnologias de segurança
é a garantia de integração entre as novas especificações de Web Services, o que
eliminaria os problemas de integração do XWSS 2.0 com JAX-WS enfrentados
durante o desenvolvimento deste trabalho.
Outra sugestão para trabalhos futuros é desenvolver um ambiente escalável
de Web Services através de cluster em servidores de aplicação. E, também, explorando
melhor os recursos de processamento de documentos XML com JAX-WS, ao invês de
somente invocação de métodos remotos. Essa proposta de cluster visa sanar o
problema de necessidade desempenho maior para o tratamento da segurança na
aplicação que foi observado durante o desenvolviemento e testes do sistema.
REFERÊNCIAS BIBLIOGRÁFICAS
ALUR, D.; CRUPI, J.; MALKS, D. Core J2EE Patterns: As Melhores Práticas e
Estratégias de Design. São Paulo: Campus, 2004.
BAUER, C.; KING, G. Hibernate em Ação. Rio de Janeiro: Ciência Moderna, 2005.
BATES, B.; SIERRA, K. SCJP: Certificação Sun para Programador Java 5. Rio
de Janeiro: AltaBooks, 2006.
BECKER, A. K.; CLARO, D. B.; SOBRAL, J. B. Web Services e XML Um Novo
Paradigma da Computação Distribuída. 2003. 16 f. Monografia (Bacharelado em
Ciências da Computação) – Departamento de Informática e Estatística, Universidade
Federal de Santa Catarina, Florianópolis.
BODOFF, S. et al. Tutorial do J2EE Enterprise Edition 1.4. Rio de Janeiro: Ciência
Moderna, 2005.
DEITEL, H. M. et al. JAVA Web Services for Experienced Programmers. New
Jersey: Prentice Hall, 2003.
GOODWIN, P. Web Services Security in Java™ Web Services Developer Pack
(Java™ WSDP). In: JAVAONE CONFERENCE – San Francisco /US. Texto que
trata sobre a segurança em Web Services. SUN MICROSYSTEMS, 2004. Disponível
em: <http://developers.sun.com/learning/javaoneonline/2004/javatechweb/TS1614.html>. Acessado em: 15 jan. 2006.
HENDRICKS, M. et al. Profissional Java Web Services. Rio de Janeiro: Alta Books,
2002.
MARQUEZAN, C. C. Estudo das características de serviços Web e de seus
cenários de aplicação. 2004. 61 f. Dissertação, Programa de Pós-Graduação em
Computação, Instituto de Informática, Universidade Federal do Rio Grande do Sul,
Porto Alegre.
SINGH, I. et al. Designing Web Services with the J2EE 1.4 Platform JAX-RPC,
SOAP, and XML Technologies. Santa Clara, Califórnia, Estados Unidos: Sun
Microsystems, 2004.
SOUSA, E. C. Sistema de Informação para uma clínica de acupuntura médica.
2005. 88 f. Trabalho de Conclusão de Curso (Bacharelado de Informática) Departamento de Ciências Exatas e da Terra, Universidade do Planalto Catarinense -
UNIPLAC, Lages.
SUN MICROSYSTEMS. JAVA API for XML Registries (JAXR). Sun Developer
Network (SDN), 2006a. Apresenta o framework para acesso de aplicações Java a
registros de Web Services. Disponível em:
<http://java.sun.com/webservices/jaxr/index.jsp>. Acesso em: 15 jan. 2006.
SUN MICROSYSTEMS. JAVA API for XML Web Services (JAX-WS). Sun
Developer Network (SDN), 2006b. Apresenta o framework para desenvolvimento de
Web Services para plataforma Java. Disponível em:
<http://java.sun.com/webservices/jaxws/index.jsp>. Acesso em: 15 jan. 2006.
SUN MICROSYSTEMS. JAVA API for XML-Based RPC (JAX-RPC). Sun
Developer Network (SDN), 2006c. Apresenta o framework para desenvolvimento de
Web Services utilizando a tecnologia RPC sobre XML para plataforma Java.
Disponível em: < http://java.sun.com/webservices/jaxrpc/index.jsp>. Acesso em: 15
jan. 2006.
SUN MICROSYSTEMS. JAVA Architecture for XML Binding (JAXB). Sun
Developer Network (SDN), 2006d. Apresenta o framework para ligamento de
esquemas XML a classes Java. Disponível em:
<http://java.sun.com/webservices/jaxb/index.jsp >. Acesso em: 15 jan. 2006.
SUN MICROSYSTEMS. JAVA Web Services Developer Pack (Java WSDP)
Version 2.0. Sun Developer Network (SDN), 2006e. Apresenta a introdução ao toolkit
de desenvolvimento de Web Services para plataforma Java. Disponível em
<http://java.sun.com/webservices/jwsdp/index.jsp>. Acesso em: 15 jan. 2006.
SUN MICROSYSTEMS. SOAP with Attachments API for Java (SAAJ). Sun
Developer Network (SDN), 2006f. Apresenta o framework para envio de mensagens
SOAP com anexos para aplicações Java. Disponível em:
<http://java.sun.com/webservices/saaj/index.jsp>. Acesso em: 15 jan. 2006.
SUN MICROSYSTEMS. The Future of Web Services Security: A Conversation
with Eve Maler. Sun Developer Network, Santa Clara - US. Texto que aborda a
entrevista com a presidente Security Work Plan Working Group of WS-I sobre o
futuro da segurança em Web Services. Disponível em:
<http://Java.sun.com/features/2003/03/Webservices-qa.html>. Acesso em: 24 nov.
2005.
SUN MICROSYSTEMS. The Java™ EE 5 Tutorial. Santa Clara, Califórnia,
Estados Unidos: Sun Microsystems, 2006g.
SUN MICROSYSTEMS. The Java™ Web Services Tutorial For Java Web
Services Developer’s Pack, v1.6. Santa Clara, Califórnia, Estados Unidos: Sun
Microsystems, 2005h.
SUN MICROSYSTEMS. The Java™ Web Services Tutorial For Java Web
Services Developer’s Pack, v2.0. Santa Clara, Califórnia, Estados Unidos: Sun
Microsystems, 2006i.
SUN MICROSYSTEMS. XML and Web Services Security (XWSS). Sun Developer
Network (SDN), 2006. Apresenta o framework de segurança para Web Services em
aplicações Java. Disponível em: <http://java.sun.com/webservices/xwss/index.jsp>.
Acesso em: 15 jan. 2006j.
UDDI. About UDDI. UDDI.org, 2006. Página que explica a funcionalidade do padrão
UDDI. Disponível em: < http://www.uddi.org/about.html>. Acesso em: 17 mar. 2006.
W3C. SOAP Version 1.2 Part 1: Messaging Framework. W3C Recommendation,
2006a. Apresenta o framework SOAP e suas especificações. Disponível em:
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624/>. Acesso em: 17 mar.
2006.
W3C. Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language. W3C Working Draft, 2006b. Documento que descreve a especificação
WSDL. Disponível em: <http://www.w3.org/TR/2003/WD-wsdl20-20031110/#intro>.
Acesso em: 17 mar. 2006.
W3C. XML-Signature Syntax and Processing. W3C Recommendation, 2006c.
Documento que descreve a especificação de assinaturas digitais em documentos XML.
Disponível em: < http://www.w3.org/TR/xmldsig-core/>. Acesso em: 17 mar. 2006.
W3C. XML Encryption Syntax and Processing. W3C Recommendation, 2006d.
Documento que descreve a especificação de criptografia em documentos XML.
Disponível em: < http://www.w3.org/TR/xmlenc-core/>. Acesso em: 17 mar. 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a
objetos. Rio de Janeiro: Elsevier: Campus, 2004.
BIBLIOGRAFIA COMPLEMENTAR
CHAPPELL, D.; IEWELL, T. Java Web Services. Estados Unidos: O´Reilly, 2002.
DEITEL, H. M. et al. XML: como programar. Porto Alegre: Bookman, 2003.
HADLEY, R. C. M. Next Generation Web Services in the Java™ Platform. In:
JAVAONE CONFERENCE – San Francisco /US. Sun Microsystems. 2005.
SUN MICROSYSTEMS. Securing Web Services — Concepts, Standards, and
Requirements. Santa Clara, Califórnia, Estados Unidos: SUN MICROSYSTEMS
2003.
APÊNDICE - ARTIGO
SEGURANÇA EM WEB SERVICES COM JAVA .................................................. 1
Segurança em Web Services com Java
Fernando Luiz Parisotto¹, Marcos André Pisching²
Departamento de Ciências Exatas e Tecnológicas – Universidade do Planalto
Catarinense (UNIPLAC)
Caixa Postal 525 – Lages – SC – Brasil
¹[email protected], ²[email protected]
Abstract. Web Services is the new trend for distributed systems, services
oriented and loosely coupled. However, for the adoption of this technology in
a corporative environment, where confidential data are transit in an ecommerce scene, it is necessary to guarantee confidencialidade of business
data, authentication of the interested parts and also integrity of the data
transmitted. This article has as objective to also present the main concepts of
the implementation of security in Web Services and the main involved
technologies in this process.
Palavras chave: Web Services; Segurança; Java.
Resumo. Web Services é a nova tendência para sistemas distribuídos,
orientados a serviços e baixamente acoplados. Porém, para a adoção desta
tecnologia em um ambiente corporativo, onde dados confidenciais transitam
em um cenário de e-commerce, é necessário se garantir confidencialidade dos
dados transacionados, autenticação das partes interessada e também
integridade dos dados a serem transmitidos. Este artigo tem como objetivo
apresentar os principais conceitos da implementação de segurança em Web
Services e também as principais tecnologias envolvidas nesse processo.
Keywords: Web Services; Security; Java.
1. Introdução
Os Web services são componentes de software baixamente acoplados que podem
reduzir a complexidade de aplicações corporativas, reduzindo custos, e permitem novos
modelos de negócio. São a nova tendência, abastecendo o e-commerce, a integração de
aplicações e também dando base a sistemas em um ambiente business-to-business
(B2B).
Uma característica importante dos Web Services é que a interação é instantânea
entre aplicação a aplicação, melhor de que entre seres humanos. Assim, quando as
empresas estiverem interessadas em trazer Web Services em sua arquitetura principal, a
segurança pôde ser a força contraria que influencia muitas empresas a não utilizar a
tecnologia. A segurança é importante para todo sistema que utiliza Web Services.
Garantir a segurança em Web services é crucial para ampla adoção da tecnologia.
Porém os padrões existentes da segurança, tais como (SSL), que é o mecanismo o mais
geralmente usado para garantir segurança em transações de e-commerce, não foram
concebidos para sua utilização em conjunto com Web Services. O fato é que os Web
Services requerem a segurança fim-a-fim ao invés da segurança ponto-a-ponto que o
SSL prove.
Este artigo apresenta uma visão geral da segurança da informação, seguida por
uma visão geral dos conceitos básicos para garantir segurança em Web services. Cobre
alguns dos padrões proeminentes da indústria desenvolvidos para fornecer soluções
detalhadas da segurança, como também a estrutura da XWS-Security que é a
implementação responsável pela segurança em Web services baseada na especificação
WSS do OASIS.
2. Conceitos sobre segurança
É importante ter uma compreensão geral da segurança da informação antes de dirigir-se
a elementos da segurança de Web Services.
Há cinco serviços de segurança gerais que abrangem as várias funções requeridas
para segurança. Estes podem também ser considerados como as exigências que definem
a segurança da informação:

Autenticação: assegura-se de que o remetente e o receptor sejam quem
reivindica ser. Os mecanismos tais como o Username/Password, Smart Cards, e
a infra-estrutura de chave pública (ICP) podem ser usadas assegurar a
autenticação.

Autorização, ou controle de acesso: Assegura-se de que uma entidade
autenticada possa alcançar somente aqueles serviços que são permitidos
alcançar. As listas do controle de acesso são usadas executar esta.

Confidencialidade: Isto assegura que a informação no armazenamento e
transportada são acessíveis somente para partes autorizadas. A criptografia é
usada assegurar o confidencialidade da mensagem.

Integridade: Assegura-se de que a informação armazenada ou transmitida não
possa ser modificada intencionalmente ou involuntariamente. As assinaturas de
Digital são usadas assegurar a integridade da mensagem.

Não repudio: Requer que nem o remetente nem o receptor de uma mensagem os
reivindicam que não emitiram/recebem a mensagem.
3. Camadas de segurança em Web Services
Segundo SINGH et al. (2004), os serviços de segurança em Web Services podem incluir
segurança em nível de transporte e segurança em nível de mensagens.
A segurança sobre a camada de transporte é aplicada na camada em que o Web
Service atua, como protocolo HTTP, assegurando o processo de comunicação de um
ponto a outro. A segurança sobre a camada de mensagem é aplicada na mensagem em
si, que o Web Service transmite, através de tecnologias de criptografia e assinatura
digital de documentos XML.
Segundo a SUN MICROSYSTEMS (2006), as principais necessidades de segurança
em um Web Service são:

Baixo acoplamento entre o serviço e o consumidor;

Segurança baseada em padrões da Internet;

Foco em prover interoperabilidade;

Neutralidade de plataforma e linguagem de programação;

Possibilidade de utilizar vários protocolos de transporte, como HTTP, SMTP,
etc.;

Suporte a interação de vários intermediários entre o consumidor do serviço e o
provedor do serviço.
E as suas principais vulnerabilidades são (SUN MICROSYSTEMS, 2006):

Interações são efetuadas através da Internet, usando protocolos que são
amigáveis a firewalls;

Uma comunicação é iniciada freqüentemente pelos consumidores do serviço que
não têm nenhum relacionamento prévio com o fornecedor de serviço;

A mensagem é baseada em texto plano.
4. Segurança sobre a camada de transporte
DEITEL et al. (2002), afirmam que atualmente a maioria das aplicações para comercio
eletrônico usam Secure Socktes Layer (SSL) para suas transações on-line. SSL é
comumente usado para garantir segurança em comunicações entre dois computadores na
Internet ou em uma rede. Opera entre os protocolos de comunicação TCP/IP como está
ilustrado pela Figura 1 e é transparente para a aplicação que o utiliza.
Figura 1. Processo de comunicação através do protocolo SSL.
O SSL utiliza a criptografia assimétrica em conjunto com a simétrica e
certificados digitais para autenticar os servidores e clientes e proteger as informações
que transitam pela Internet. O processo de comunicação é iniciado pelo cliente, envia
uma mensagem para o servidor, o servidor responde a mensagem enviando o seu
certificado digital ao cliente para autenticação. Usando a chave pública do servidor para
se comunicar seguramente, o cliente e o servidor negociam chaves simétricas para
continuar a transmissão. Essa chave é usada somente durante o processo da transação.
Uma vez trocada a chave simétrica a comunicação procede entre o cliente e o
servidor usando esta chave. Dados criptografados passam pelo canal de comunicação
TCP/IP como qualquer pacote que viaja pela Internet. Entretanto, antes de mandar uma
mensagem por TCP/IP o protocolo SSL quebra a informação em blocos, comprime-os e
os criptografa. Conseqüentemente para o receptor antes de o pacote chegar a aplicação o
protocolo SSL a descriptografa o pacote, os extrai e os monta para ser entregue a
aplicação, tornado o processo transparente (DEITEL, 2003).
Esses processos extras na comunicação provêem uma camada de segurança entre
aplicações que fazem uso do TCP/IP para se comunicar. O objetivo principal do SSL é
garantir a segurança de ponto a ponto em conexões ou transmissões de dados para um
computador a outro em uma rede, seja ela local ou remota, também provendo meio de
autenticação entre as duas partes (DEITEL, 2003).
O protocolo SSL provê para aplicações três serviços de segurança (DEITEL, 2003):

Autenticação: o servidor apresenta ao cliente um conjunto de credenciais e
certificados que provam que este serviço é o que diz ser.

Confidencialidade: os dados transmitidos por SSL são criptografados, tornando
impossível a legibilidade dos mesmos por terceiros que estejam no caminho da
comunicação entre o cliente e o servidor.

Integridade: SSL garante um meio de verificação de que os dados por ele
transmitidos não foram alterados.
Segundo HENDRICKS et al. (2002), o SSL é um protocolo sofisticado que está
sendo muito usando na Internet, e que fornece uma boa camada de segurança, mas que
juntamente com outros serviços em nível de transporte, não deixa de apresentar
problemas quando aplicado a Web Services.
Múltiplos Web Services podem ser combinados para a formação de uma aplicação
maior, orientada a serviços. Devido a isso esta aplicação necessita fazer inúmeras
chamadas e conexões com outros Web Services, e os mesmo podem também fazer uso
de outros Web Services e assim consecutivamente. O que torna o SSL um padrão
inapropriado para garantir a segurança de informações nesse tipo de sistema, pois SSL
prove segurança de ponto-a-ponto, maquina a maquina e não fim-a-fim como é preciso
neste caso, SSL não chega a descer para o próximo nível da cadeia de serviços, ele fica
apenas situado entre as conexões.
O protocolo SSL possui uma série de limitações quando se trata de sua
aplicabilidade em Web Services, que podem ser resumidas em (GOODWIN, 2004):

SSL prove segurança de ponto-a-ponto e opera entre nós da rede (não entre
aplicações). Para Web Services é necessário segurança de fim-a-fim onde nós
intermediários podem existir entre um processo de troca de mensagem;

SSL opera no nível de transporte e não no nível de mensagem. As mensagens
estão protegidas somente enquanto são transmitidas, não são seguras por si só,
necessitam de um canal seguro de comunicação;

SSL não suporta não-repúdio. Não é possível provar que outra entidade efetuou
tal transação ou requisitou tal serviço;

SSL não suporta criptografia customizada ou em parte. Utilizando SSL para
transportar um documento XML grande, seria necessário criptografa-lo por
completo, e não somente as informações que seriam consideradas confidenciais.
Segundo HENDRICKS et al. (2002), a implementação de um Web Service que faça
uso de segurança sobre a camada de transporte HTTP com SSL é razoavelmente
simples. Ele afirma que não há necessidade de grandes alterações no código da
aplicação, apenas é preciso que se configure corretamente o servidor, registrando um
domínio seguro onde o Web Service está hospedado e obtendo um certificado digital
válido de uma autoridade certificadora para ser associado ao servidor. Para que isso
possa ser feito é necessário que o servidor onde a aplicação esteja hospedada suporte
comunicações através do protocolo SSL.
Porém, deve levar em consideração a carga extra de trabalho que o servidor sofrerá
para atender as requisições criptografadas por SSL, afirma DEITEL et al. (2003).
Existem soluções em hardware especializadas para tratar do processamento de
requisições SSL, como por exemplo, uma placa PCI que pode ser conectada ao servidor
e que fornece um processador que implementa a baixo nível o processamento de SSL,
afirmam DEITEL et al. (2003), fornecem um ótimo desempenho para a tarefa.
Baseado nas afirmações anteriores da SUN MICROSYSTEMS (2006), sobre as
necessidades de segurança em Web Services, deduz-se que a segurança sobre a camada
de transporte não é a melhor tecnologia de segurança a ser aplicada nesse tipo de
sistema. Devido ao fato de ser dependente de protocolo de transmissão (HTTP) e de não
suportar a existência transparente de intermediários na comunicação. Porém, pode ser
aplicada com sucesso em um sistema que não necessite destas características para o seu
funcionamento.
5. Segurança sobre camada de mensagem
“Segurança no nível de mensagem é diferente do que se usa geralmente para prover
segurança em Web Services hoje em dia. O que é feito hoje é pego a mensagem que é
um pedaço de dados vulnerável que todo mundo pode olhar, todo mundo pode mudar.
Para prever isso é pego esse pedaço de dados e a empurramos em um tubo de aço para o
seu destinatário que esta conectado na outra ponta do tubo. Esse tubo é o que chamamos
de segurança a nível de transporte que protege a mensagem entre a origem e seu destino.
Segurança no nível de mensagem é diferente, segurança a nível de mensagem pega esse
conjunto de dados e a embala em uma concha do mesmo tipo de aço e agora a
mensagem esta segura por si só. Está segura antes de ser enviada, esta segura quando é
recebida e após ser recebida também. Agora não precisamos mais do tubo de aço. Agora
podemos usar qualquer tubo que temos disponível para mandar a mensagem. Também
podemos armazenar a mensagem depois de ser recebida, o que nos da à habilidade de
recuperá-la e verificar suas informações de segurança, como em situações com
assinatura digital, em que se quer provar que alguém quem mandou essa mensagem
realmente é quem diz ser. Estas características estão disponíveis para a sua aplicação, o
que significa partir do momento que se sabe o que a aplicação esta fazendo e da
estrutura da mensagem, é possível quebra-la e abri-la e se pode ver pedaços individuais
da mensagem, pode-se embala-los e criptografa-los, pode-se assina-los, assinar pedaços
de diferentes formas, pode-se embalar toda a mensagem, criptografa-la ou assina-la.
Partindo disto, essa tecnologia pode oferecer um ótimo meio de controle para a
aplicação acessar um maior conjunto de opções de segurança.” (GOODWIN, 2004).
Segundo a SUN MICROSYSTEMS (2006), a segurança sobre a camada de
mensagem faz uso de uma serie de mecanismos, tais como: criptografia, autenticação e
assinaturas digitais. As principais vantagens desse esquema de segurança na camada da
mensagem são:

A segurança fica com a mensagem através de todos os nós e depois da
mensagem chegar ao seu destinatário;

A segurança é granular, pode ser aplicada em diferentes partes da mensagem,
incluindo seus anexos;

Pode ser usada em conjunto com intermediários na rede;

É independente de ambiente e de protocolo de transporte.
6. Organizações envolvidas no desenvolvimento de tecnologias de segurança
em nível de mensagem para Web Services
Segundo a SUN MICROSYSTEMS (2006), as seguintes organizações trabalham para o
desenvolvimento de especificações, tecnologias e ferramentas para segurança em Web
Services:

The World Wide Web Consortium (W3C)
o XML Encryption: esta especificação prove requerimentos para o
processamento e criptografia de documentos expressados pela sintaxe
XML;
o XML Digital Signature: esta especificação define um meio de representar
assinaturas digitais em documentos XML através de sua sintaxe e
semântica;
o XML Key Management Specification: esta especificação define
protocolos para distribuição e registro de chaves publicas em
documentos XML;

Organization for Advancement of Structured Information Standards (OASIS)
o Web Services Security (WSS), SOAP Message Security: Esta
especificação descreve aprimoramentos para o protocolo SOAP que
prove integridade, confidencialidade e autenticação na mensagem, esta
especificação será tratada com mais detalhes adiantes neste artigo;
o Security Assertion Markup Language (SAML): a especificação SAML
define um mecanismo baseado em XML para segurança de transações
B2B, B2C e e-commerce. SAML define um framework para troca de
informações sobre autenticação e autorização, desta forma SAML prove
um meio de interoperabilidade de definições de segurança entre sistemas
distintos;
o eXtensible Access Control Markup Language (XACML): a especificação
XACML define uma linguagem para expressão de políticas de segurança
baseado em documentos XML;

Web Services Interoperability Organization (WS-I): diferente da W3C e da
OASIS, a WS-I desenvolve perfis de o que usar, e como usar as tecnologias
existentes para promover segurança em Web Services. Alguns desses perfis são:
o Basic Security Profile (BSP) que fornece um guia de uso do framework
WSS;
o REL Token Profile que é o guia de como usar a linguagem de expressão
de direitos (Rights Expression Language);
o SAML Token Profile: guia de uso da tecnologia SAML;
o Security Challenges, Threats, and Countermeasures (Desafios, ameaças,
e contramedidas de segurança): é um documento escrito pela Web
Services Interoperability Organization (WS-I), que visa identificar
ameaças de segurança em uma aplicação que faz uso de Web Services e
em sua infra-estrutura. Este documento também visa promover uma
tecnologia apropriada para tratar essa ameaça.
7. API de segurança em nível de mensagem para Web Services na
plataforma Java
O framework responsável pela segurança em Web Services na plataforma Java é o
XWS-Security (XML and Web Serivices Security). Este faz parte do JWSDP (Java Web
Services Developer Pack), que provê um meio a desenvolvedores de aplicar segurança
em aplicações desenvolvidas com JAX-RPC (Java API for XML Based RPC), JAX-WS
(Java API for Web Services) ou SAAJ (SOAP with Attanchments API for Java), através
de configurações de políticas de segurança de requisição e resposta no nível de serviço,
porta ou operação. Esta implementação de XWS-Security provê segurança para Web
Services no nível de mensagem e implementa os padrões de Segurança em Web Services
(WSS) propostos pela OASIS.
O framework XWS-Security fornece ao desenvolvedor de aplicações Web
Services uma ampla variedade de opções de definição de segurança em seu aplicativo. O
framework faz uso de uma série de tecnologias relacionadas que possibilita uma
configuração flexível e interoperável na camada de segurança do aplicativo.
O meio de se aplicar a segurança é através de arquivos XML de configuração,
usados em conjunto com o descritor da aplicação que é um documento requerido em
toda aplicação Enterprise para plataforma Java EE.
Segundo a SUN MICROSYSTEMS (2006), uma aplicação Web Services pode ser
segura conforme os seguintes cenários:

Assinando e verificando partes de uma mensagem SOAP e seus anexos (fazendo
uso da tecnologia XML Digital Signature);

Criptografando ou descriptografando partes de uma mensagem SOAP e seus
anexos (fazendo uso da tecnologia XML Encryption);

Enviando informações de identificação e autorização de usuários junto com a
mensagem SOAP (fazendo uso da tecnologia SAML).
8. Considerações finais
Ao final do estudo realizado, chegou-se a conclusão de que existem duas maneiras de se
aplicar segurança em Web Services. Através da segurança sobre a camada de transporte
(atualmente HTTP / SSL), o que limita muito a aplicação no sentido de uma arquitetura
orientada a serviços. E, também, há a possibilidade de se aplicar segurança na camada
da mensagem, através de frameworks como XWSS que implementam padrões
específicos da indústria sobre segurança em Web Services.Através das informações
obtidas nesse estudo, conclui-se que a segurança sobre a camada de mensagem é a mais
indicada por aplicações que façam uso de Web Services, devido ao fato desta tecnologia
ser desenvolvida especialmente para suprir as necessidade de sistemas que utilizem essa
arquitetura de serviço, e também por cobrir as falhas apresentadas na segurança sobre a
camada de transporte.
Referencias
DEITEL, H. M. et al. JAVA Web Services for Experienced Programmers. New Jersey:
Prentice Hall, 2003.
GOODWIN, P. Web Services Security in Java™ Web Services Developer Pack (Java™
WSDP). In: JAVAONE CONFERENCE – San Francisco /US. Texto que trata sobre
a segurança em Web Services. SUN MICROSYSTEMS, 2004. Disponível em:
<http://developers.sun.com/learning/javaoneonline/2004/javatechweb/TS1614.html>. Acessado em 15 de janeiro de 2006.
HENDRICKS, M. et al. Profissional Java Web Services. Rio de Janeiro: Alta Books,
2002.
SINGH, I. et al. Designing Web Services with the J2EE 1.4 Platform JAX-RPC, SOAP,
and XML Technologies. Santa Clara, Califórnia, Estados Unidos: Sun Microsystems,
2004.
SUN MICROSYSTEMS. JAVA Web Services Developer Pack (Java WSDP) Version
2.0. Sun Developer Network (SDN), 2006e. Apresenta a introdução ao toolkit de
desenvolvimento de Web Services para plataforma Java. Disponível em
<http://java.sun.com/webservices/jwsdp/index.jsp>. Acesso em: 15 jan. 2006.