SEGURANÇA EM WEB SERVICES COM JAVA

Transcrição

1 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.

2 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.

3 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.

4 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.

5 SUMÁRIO LISTA DE ILUSTRAÇÕES... VIII LISTA DE SIGLAS... X RESUMO... XII ABSTRACT... XIII 1 INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia WEB SERVICES O que são Web Services? Arquitetura dos Web Services, padrões e tecnologias Troca de Mensagens XML SOAP Descrição dos Web Services WSDL Publicação e descoberta do Web Service UDDI Java Web Services Java Web Services Developer Pack Java API for XML Web Services Java API for XML-Based RPC Java API for XML Registries Java Architecture for XML Binding SOAP with Attachments API for Java XML and Web Services Security Conclusão SEGURANÇA EM WEB SERVICES Introdução Visão geral sobre segurança Identificação e autenticação Autorização Integridade... 32

6 3.2.4 Privacidade Não-repúdio Técnicas e tecnologias de segurança Criptografia Assinaturas digitais Certificados digitais Camadas de segurança em Web Services Segurança sobre a camada de transporte Segurança sobre camada de mensagem Conclusão ANÁLISE E MODELAGEM DO SISTEMA Concepção Sumário executivo Levantamento de requisitos Lista de consultas Requisitos suplementares Organização de requisitos Listas de caso de uso Lista de conceitos e operações cadastrais Fase de elaboração Fase do projeto Descrição do sistema Arquitetura do sistema Diagrama de classes Padrões de projeto utilizados Session Fachade Conclusão DESENVOLVIMENTO E CONFIGURAÇÃO DO SISTEMA Requisitos de software Instalação e configuração do ambiente Instalação do Java Standard Edition Developer Kit 5 e configuração das variáveis de ambiente: Instalação do PostgreSQL 8.1: Instalação do eclipse 3.2: Instalação do Sun Java System Application Server Platform Edition Codificação do sistema Camada de domínio Fachada do sistema Camada de persistência Implementação da segurança Arquivo de segurança Codificação dos CallbackHandlers Arquivos de configuração do sistema Arquivos do servidor Arquivos do cliente Desenvolvimento do cliente Web Service

7 5.7 Demonstração do ambiente Web Service não seguro Web service seguro Conclusão CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS BIBLIOGRAFIA COMPLEMENTAR APÊNDICE - ARTIGO

8 LISTA DE ILUSTRAÇÕES FIGURA 1 - Arquitetura dos Web Services FIGURA 2 - Modelo de fluxo de um processo de requisição a um repositório UDDI FIGURA 3 - Criptografia simétrica FIGURA 4 - Criptografia assimétrica FIGURA 5 - Processo de Handshake FIGURA 6 - Processo de assinatura digital de um documento FIGURA 7 - Processo de comunicação através do protocolo SSL FIGURA 8 - Modelo de conceitual FIGURA 9 - Arquitetura do sistema FIGURA 10 - Diagrama de classe FIGURA 11 - Modelo lógico do banco de dados FIGURA 12 - Diagrama de classe do padrão Session Façade FIGURA 13 - Imagem da janela principal do sistema QUADRO 1 - Mensagem SOAP QUADRO 2 - Código de resposta a uma requisição SOAP com resultado falho QUADRO 3 - Documento WSDL que apresenta um método sayhello por um Web Service QUADRO 4 - Cadastro de Clientes QUADRO 5 - Cadastro de Produtos QUADRO 6 - Cadastro de Ordem de Compra QUADRO 7 - Cadastro de Categoria QUADRO 8 - Lista de consultas QUADRO 9 - Requisitos suplementares QUADRO 10 - Lista de caso de uso QUADRO 11 - Lista de operações cadastrais QUADRO 12 - Expansão do caso de uso Ordem de Compra QUADRO 13 - Classe Endereço QUADRO 14 - Implementação da classe Cliente QUADRO 15 - Implementação da classe Categoria QUADRO 16 - Implementação da classe Produto QUADRO 17 - Implementação da classe OrdemCompra QUADRO 18 - Implementação da classe ProdutoOrdemCompra

9 QUADRO 19 - Interface que representa a Fachada do Cliente QUADRO 20 - Interface que representa a Fachada do Administrador QUADRO 21 - Arquivo de configuração da JPA, persistence.xml QUADRO 22 - Implementação do Web Service Administrador QUADRO 23 - Implementação do Web Service Cliente QUADRO 24 - Arquivo de segurança do Web Service Administrador QUADRO 25 - Arquivo de segurança do Web Service Cliente QUADRO 26 - Implementação da classe SecurtyCallbackHandler QUADRO 27 - Implementação da classe DefaultSecurityHandler QUADRO 28 - Implementação da classe AdministradorSecurityHanler QUADRO 29 - Implementação da classe ClienteSecurityHandler QUADRO 30 - Arquivo MANIFEST.MF do projeto Cliente QUADRO 31 - Quadro demonostrando a troca de mensagens não seguras QUADRO 32 - Quadro demonstrando a troca de mensagens seguras

10 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

11 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

12 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.

13 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 e- commerce, 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.

14 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

15 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

16 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

17 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,

18 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.

19 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,

20 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

21 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;

22 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.

23 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

24 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.

25 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 POST /soap/servlet/rpcrouter HTTP/1.0 Host: localhost:8070 Content-Type: text/xml Content-Length: 461 SOAPAction: "" <env:envelope xmlns:env=" <env:header> <n:alertcontrol xmlns:n=" <n:priority>1</n:priority> <n:expires> t14:00:00-05:00</n:expires> </n:alertcontrol> </env:header> <env:body> <m:alert env:encodingstyle=" xmlns:m=" <m:msg>fazer compras para o almoço.</m:msg> </m:alert> </env:body> </env:envelope> O Quadro 1 mostra o exemplo de como uma mensagem SOAP é codificada

26 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. <env:envelope xmlns:env=" xmlns:xsd=" xmlns:xsi=" xmlns:enc=" xmlns:ns0="urn:helloservice" env:encodingstyle=" <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

27 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

28 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

29 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 XML- RPC) 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:

30 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.

31 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. <?xml version="1.0" encoding="utf-8"?> <definitions name="newwebservice" targetnamespace="urn:newwebservice/wsdl" xmlns:tns="urn:newwebservice/wsdl" xmlns=" xmlns:xsd=" xmlns:ns2="urn:newwebservice/types" xmlns:soap=" <types> <schema targetnamespace="urn:newwebservice/types" xmlns:tns="urn:newwebservice/types" xmlns:soap11-enc=" xmlns:xsi=" xmlns:wsdl=" xmlns=" <complextype name="sayhello"> <sequence/> </complextype> <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> <message name="newwebservicesei_sayhello"> <part name="parameters" element="ns2:sayhello"/> </message> <message name="newwebservicesei_sayhelloresponse"> <part name="result" element="ns2:sayhelloresponse"/> </message> <porttype name="newwebservicesei">

32 <operation name="sayhello"> <input message="tns:newwebservicesei_sayhello"/> <output message="tns:newwebservicesei_sayhelloresponse"/> </operation> </porttype> <binding name="newwebserviceseibinding" type="tns:newwebservicesei"> <soap:binding transport=" style="document"/> <operation name="sayhello"> <soap:operation soapaction=""/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="newwebservice"> <port name="newwebserviceseiport" binding="tns:newwebserviceseibinding"> <soap:address location="replace_with_actual_url"/> </port> </service> </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

33 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

34 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.

35 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 < 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

36 funcionalidades 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.

37 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) 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) 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

38 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) 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) 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).

39 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) 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

40 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.

41 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.

42 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;

43 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) 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. ( Métodos como impressão digital, reconhecimento da face, identificação pela íris,

44 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 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.

45 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) 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.

46 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) 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

47 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 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;

48 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

49 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 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).

50 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

51 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,

52 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 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

53 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.

54 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 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

55 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 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

56 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):

57 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 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.

58 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.

59 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 é

60 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 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

61 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 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;

62 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.

63 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

64 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.

65 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

66 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.

67 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 Informações do cliente N.F. 2.2 Identificação do cliente N.F. 2.2 Login do cliente As informações sobre o cliente são: nome*; sobrenome*; endereço(rua, numero, bairro, cidade, estado, cep, complemento)*; cpf *; login*; password*. Especificação O cliente deve ser identificado pelo seu cpf ou seu login. Interface X O cliente deve ter um login e este deve ser unico. Especificação 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 Informações do Produto N.F. 3.2 Identificação do Produto As informações sobre o produto são: nome*; preço por unidade*; quantidade em estoque* identificador*. Especificação O produto deve ser identificado pelo seu nome ou identificador. 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. X

68 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*; produtos/quantidade*; data da realização*; Especificaçã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*; unidade*; identificador*; Especificação 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

69 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 Administrador, Cliente Cliente F4, Administrador Ordem de compra F1, F2, F3, F4, F5 Administrador, Cliente (somente as realizadas por ele). Categoria F1, F4 Administrador, Cliente 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 Restrição Categoria Desejável Permanente S1 Níveis de segurança S2 Plataforma S3 Formas de acesso S4 Banco de Dados 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. O sistema deverá ser desenvolvido para plataforma Java EE. O ambiente deverá ser acessado através de Web Services. O Banco de Dados deverá ser compatível com o padrão SQL92. S5 Autenticação Todas as operações a serem realizadas devem ser autenticadas e autorizadas. S6 Privacidade Todos os dados transmitidos devem ser criptografados. Segurança Arquitetura Arquitetura Arquitetura Segurança Segurança X X X X X X

70 Nome Restrição Categoria Desejável Permanente S7 Não-repúdio Toda realização de uma Ordem de compra deve ser assinada digitalmente pelo cliente. Segurança 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) 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 Descrição Referências Cruzadas O cliente faz uma requisição ao Realizar uma Ordem de Compra Cliente sistema informando os produtos que o F4, F3, F2 mesmo deseja comprar, juntamente com seu cartão de credito 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

71 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 Referências Cruzadas Cliente Produto Ordem de Compra Categoria 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. F1, F2, F3, F4, S5, S6, S7 A alteração, exclusão ou inserção de Produto poderá ser X X X X F3, F1 realizada somente por um administrador. A criação de uma nova Ordem de Compra poderá X X X somente ser realizada por um Cliente através do caso de uso. X X X X A alteração, exclusão ou inserção de Categorias poderá ser realizada somente por um administrador. 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.

72 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.

73 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 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

74 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 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

75 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 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.

76 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.

77 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

78 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) 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

79 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 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,

80 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.

81 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);

82 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: 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 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 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) Instalação do eclipse 3.2:

83 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) 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 copiado para o diretório AS_HOME\domains\domain1\lib o arquivo postgresql 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 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

84 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 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,

85 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 da JPA, que indica que esta classe é uma entidade persistível; Ter uma 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

86 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 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 public class Endereco implements Serializable { public Endereco() { private String rua; private Integer numero; private String bairro; private String cidade; private String uf; private 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;

87 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 que representa o conjunto é uma consulta pré-processada, escrita na linguagem JPQL (Java Persistence Query Languare, (SUN MICROSYSTEMS, 2006g), liguagem própria para consulta em ORM; A unique=true) que indica que o valor da coluna mapeada não deve ser nulo e deve ser único; A mappedby = "cliente") que indica um relacionamento um para muitos com um objeto OrdemCompra no atributo cliente. Também, outro diferencial é a 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.

88 QUADRO 14 - Implementação da classe Cliente. package net.uniplac.tcc.segurancaws.model; import java.io.serializable; import java.util.collection; import javax.persistence.cascadetype; import javax.persistence.column; import javax.persistence.embedded; import javax.persistence.entity; import javax.persistence.id; import javax.persistence.namedqueries; import javax.persistence.namedquery; = "Cliente.findByCpf", query = "SELECT c FROM Cliente c WHERE c.cpf = = "Cliente.findByNome", query = "SELECT c FROM Cliente c WHERE c.nome = = "Cliente.findByLogin", query = "SELECT c FROM Cliente c WHERE c.login = = "Cliente.findByPassword", query = "SELECT c FROM Cliente c WHERE c.password = = "Cliente.findAll", query = "SELECT c FROM Cliente = "Cliente.findByCidade", query = "SELECT c FROM Cliente c WHERE c.endereco.cidade = = "Cliente.findByUf", query = "SELECT c FROM Cliente c WHERE c.endereco.uf = = "Cliente.findByCep", query = "SELECT c FROM Cliente c WHERE c.endereco.cep = = "Cliente.findByBairro", query = "SELECT c FROM Cliente c WHERE c.endereco.bairro = = "Cliente.findByRua", query = "SELECT c FROM Cliente c WHERE c.endereco.rua = :rua") ) public class Cliente implements = false, unique = true) private String cpf; private String = true) private String login; private String private Endereco = CascadeType.ALL, mappedby = "cliente") private Collection<OrdemCompra> ordenscompra; public Cliente() { // getters and 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;

89 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 QUADRO 15 - Implementação da classe Categoria. package net.uniplac.tcc.segurancaws.model; import java.io.serializable; import java.util.collection; import javax.persistence.cascadetype; import javax.persistence.column; import javax.persistence.entity; import javax.persistence.generatedvalue; import javax.persistence.generationtype; import javax.persistence.id; import javax.persistence.namedqueries; import javax.persistence.namedquery; = "Categoria.findById", query = "SELECT c FROM Categoria c WHERE c.idcategoria = = "Categoria.findByNome", query = "SELECT c FROM Categoria c WHERE c.nome = = "Categoria.findByUnidade", query = "SELECT c FROM Categoria c WHERE c.unidade = = "Categoria.findAll", query = "SELECT c FROM Categoria c") ) public class Categoria implements private Integer = true) private String nome; private String = CascadeType.ALL, mappedby = "categoria") private Collection<Produto> produtos; public Categoria() { // getters and public Set<Produto> getprodutos() { return produtos; public void addproduto(produto produto) { produto.setcategoria(this); getprodutos().add(produto);

90 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 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 java.io.serializable; import javax.persistence.entity; import javax.persistence.generatedvalue; import javax.persistence.generationtype; import javax.persistence.id; import javax.persistence.manytoone; import javax.persistence.namedqueries; = "Produto.findByIdProduto", query = "SELECT p FROM Produto p WHERE p.idproduto = = "Produto.findByNome", query = "SELECT p FROM Produto p WHERE p.nome = = "Produto.findByPrecoUnitario", query = "SELECT p FROM Produto p WHERE p.precounitario = = "Produto.findByQdtEstoque", query = "SELECT p FROM Produto p WHERE p.qdtestoque = = "Produto.findByCategoria", query = "SELECT p FROM Produto p WHERE p.categoria = = "Produto.findAll", query = "SELECT p FROM Produto p JOIN p.categoria c") ) public class Produto implements private Integer id; private String nome; private Double precounitario; private int private Categoria categoria;

91 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 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 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 java.io.serializable; import java.text.dateformat; import java.util.collection; import java.util.date; import javax.persistence.cascadetype; import javax.persistence.entity; import javax.persistence.generatedvalue; import javax.persistence.generationtype; import javax.persistence.id; import javax.persistence.manytoone; import javax.persistence.namedqueries; import javax.persistence.namedquery; import javax.persistence.onetomany; import javax.persistence.temporal; import javax.persistence.temporaltype; = "OrdemCompra.findByIdOrdemCompra", query = "SELECT o FROM OrdemCompra o WHERE o.idordemcompra = = "OrdemCompra.findByDataRealizacao", query = "SELECT o FROM OrdemCompra o WHERE o.datarealizacao = = "OrdemCompra.findByCliente", query = "SELECT o FROM OrdemCompra o JOIN o.cliente c WHERE o.cliente = = "OrdemCompra.findAll", query = "SELECT o FROM OrdemCompra o JOIN o.cliente c") ) public class OrdemCompra implements private Integer id; private String private Date private Cliente = CascadeType.ALL, mappedby = "ordemcompra") private Collection<ProdutoOrdemCompra> listaprodutoordemcompra; public OrdemCompra() { // getters and setters, equals, hashcode, tostring...

92 @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 java.io.serializable; import javax.persistence.entity; import javax.persistence.generatedvalue; import javax.persistence.generationtype; import javax.persistence.id; import javax.persistence.manytoone; import javax.persistence.namedqueries; import javax.persistence.namedquery; import javax.xml.bind.annotation.xmlelement; = "ProdutoOrdemCompra.findByIdProdutoOrdemCompra", query = "SELECT p FROM ProdutoOrdemCompra p WHERE p.idprodutoordemcompra = = "ProdutoOrdemCompra.findByQtdVendido", query = "SELECT p FROM ProdutoOrdemCompra p WHERE p.qtdvendido = = "ProdutoOrdemCompra.findByOrdemCompra", query = "SELECT p FROM ProdutoOrdemCompra p WHERE p.ordemcompra = = "ProdutoOrdemCompra.findByProduto", query = "SELECT p FROM ProdutoOrdemCompra p WHERE p.produto = = "ProdutoOrdemCompra.findOrdemCompraByProduto", query = "SELECT p.ordemcompra FROM ProdutoOrdemCompra p WHERE p.produto = :produto") ) public class ProdutoOrdemCompra implements private Integer id; private int private OrdemCompra private Produto produto; public ProdutoOrdemCompra() { // getters and setters, equals, hashcode, public double getprecototal() { return getproduto().getprecounitario() * public OrdemCompra getordemcompra() { return this.ordemcompra;

93 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; sistema. A seguir é apresentado as duas interfaces que compõem a fachada do

94 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 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 net.uniplac.tcc.segurancaws.model.categoria; import net.uniplac.tcc.segurancaws.model.ordemcompra; import net.uniplac.tcc.segurancaws.model.produto; import public interface ClienteWebServiceIF = "recuperar-produtos") public List<Produto> = "recuperar-categorias") public List<Categoria> = "recuperar-ordens-de-compra") public List<OrdemCompra> recuperarordenscompra(string = "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 net.uniplac.tcc.segurancaws.model.categoria; import net.uniplac.tcc.segurancaws.model.cliente; import net.uniplac.tcc.segurancaws.model.ordemcompra; import public interface AdministradorWebServiceIF = "recuperar-categorias") public List<Categoria> recuperarcategorias();

95 @WebMethod(operationName = "recuperar-produtos") public List<Produto> = "recuperar-clientes") public List<Cliente> = "recuperar-todas-ordens-de-compra") public List<OrdemCompra> = "salvar-produto") public void saveproduto(@webparam(name = "produto") Produto produto) throws = "salvar-cliente") public void savecliente(@webparam(name = "cliente") Cliente cliente) throws = "salvar-categoria") public void savecategoria(@webparam(name = "categoria") Categoria categoria) throws = "excluir-produto") public void deleteproduto(@webparam(name = "produto") Produto produto) throws = "excluir-cliente") public void deletecliente(@webparam(name = "cliente") Cliente cliente) throws = "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 interface no ) que neste 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 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

96 seguinte 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

97 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=" xmlns:xsi=" xsi:schemalocation=" //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

98 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 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 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

99 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 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 javax.jws.webservice; import javax.persistence.entitymanager; import javax.persistence.entitymanagerfactory; import javax.persistence.persistence; import javax.persistence.query; import net.uniplac.tcc.segurancaws.model.categoria; import net.uniplac.tcc.segurancaws.model.cliente; import net.uniplac.tcc.segurancaws.model.ordemcompra; import = "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;

100 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();

101 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();

102 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 java.util.date; import java.util.list; import java.util.logging.level; import java.util.logging.logger; import javax.jws.webservice; import javax.persistence.entitymanager; import javax.persistence.entitymanagerfactory; import javax.persistence.persistence; import javax.persistence.query; import net.uniplac.tcc.segurancaws.model.categoria; import net.uniplac.tcc.segurancaws.model.cliente; import net.uniplac.tcc.segurancaws.model.ordemcompra; import net.uniplac.tcc.segurancaws.model.produto; import = "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();

103 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

104 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) 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

105 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 da classe que implementa o serviço. O Quadro 24 apresenta a codificação do arquivo wsadministrador_sercurity_config.xml referente 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=" xmlns:xsi=" xsi:schemalocation=" 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

106 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 (wsadministrador_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=" xmlns:xwss=" xsi:schemalocation=" xwss.xsd "> <xwss:service conformance="bsp"> <xwss:port name= "{

107 <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= "{ <xwss:securityconfiguration dumpmessages="true"> <xwss:requireencryption /> <xwss:requiresignature /> <xwss:requireusernametoken passworddigestrequired="false" /> </xwss:securityconfiguration> </xwss:operation> </xwss:port> <xwss:sign> <xwss:x509token certificatealias="provedor" /> </xwss:sign> <xwss:encrypt> <xwss:x509token certificatealias="consumidor" /> </xwss:encrypt> <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

108 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 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

109 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

110 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,

111 "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 {

112 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.

113 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 java.io.inputstream; import java.util.properties; import java.util.logging.level; import 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");

114 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.

115 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 javax.persistence.entitymanager; import javax.persistence.persistencecontext; import javax.persistence.query; import javax.security.auth.callback.callback; import 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 = "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;

116 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 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

117 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 Arquivos do cliente client-security-env.properties: este arquivo é similar ao

118 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 wscliente_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 elemento <enableasyncmapping>true</enableasyncmapping> nos arquivos bindings. 5.6 Desenvolvimento do cliente Web Service Com intuito de demonstração do ambiente proposto pelo trabalho, foi

119 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.

120 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

121 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 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.

122 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=" <SOAP-ENV:Header /> <SOAP-ENV:Body> <ns2:fazer-compra xmlns:ns2=" <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> </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=" <SOAP-ENV:Header /> <SOAP-ENV:Body> <ns2:fazer-compraresponse xmlns:ns2=" /> </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.

123 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 QUADRO 32 - Quadro demonstrando a troca de mensagens seguras. <?xml version="1.0" encoding="utf-8"?> <!-- 14/11/ :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=" <SOAP-ENV:Header> <wsse:security xmlns:wsse= " SOAP-ENV:mustUnderstand="1"> <wsse:binarysecuritytoken xmlns:wsu= " EncodingType= " 1.0#Base64Binary" ValueType= " wsu:id="xwssgid "> 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=" <xenc:encryptionmethod Algorithm=" /> <ds:keyinfo xmlns:ds=" <wsse:securitytokenreference> <wsse:reference URI="#XWSSGID " ValueType= " /> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>

124 UqbuRuPfNzcR9FV1EjpzfXFf1S4+8bO+5natxSj9mASaFCGblsm6Zq4A5nU02Uz3vWgLx6 MCJbp+qJJ3ji54H8baoul7donSwnw86hGEsLQ48WELr7EdSg91Mh6rvuJedg10eQTYBvg/ i9kssjydbakcmxpun0khp9wlvs77opu= </xenc:ciphervalue> </xenc:cipherdata> <xenc:referencelist> <xenc:datareference URI="#XWSSGID " /> </xenc:referencelist> </xenc:encryptedkey> <wsse:binarysecuritytoken xmlns:wsu=" 1.0.xsd" EncodingType= " 1.0#Base64Binary" ValueType=" 1.0#X509v3" wsu:id="xwssgid "> 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=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <InclusiveNamespaces xmlns=" PrefixList="wsse SOAP-ENV" /> </ds:canonicalizationmethod> <ds:signaturemethod Algorithm=" /> <ds:reference URI="#XWSSGID "> <ds:digestmethod Algorithm=" /> <ds:digestvalue> 44fPX8/ouOEEJFgIDwwfU2AUn4g= </ds:digestvalue> </ds:reference> <ds:reference URI="#XWSSGID "> <ds:digestmethod Algorithm=" /> <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=" 1.0.xsd" wsu:id="xwssgid "> <wsse:reference

125 URI="#XWSSGID " ValueType=" 1.0#X509v3" /> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> <wsu:timestamp xmlns:wsu=" 1.0.xsd" wsu:id="xwssgid "> <wsu:created> t18:21:20z</wsu:created> <wsu:expires> t18:21:25z</wsu:expires> </wsu:timestamp> <wsse:usernametoken xmlns:wsu=" 1.0.xsd" wsu:id="xwssgid "> <wsse:username>fernando</wsse:username> <wsse:password Type= " 1.0#PasswordText"> **** </wsse:password> <wsse:nonce EncodingType= " 1.0#Base64Binary"> INvSjLxkOXPDLyGRCw0lblyv </wsse:nonce> <wsu:created> t18:21:20z</wsu:created> </wsse:usernametoken> </wsse:security> </SOAP-ENV:Header> <SOAP-ENV:Body xmlns:wsu=" 1.0.xsd" wsu:id="xwssgid "> <xenc:encrypteddata xmlns:xenc=" Id="XWSSGID " Type=" <xenc:encryptionmethod Algorithm=" /> <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

126 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 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

127 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 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 ( A solução proposta se encontra descrita no capítulo.

128 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

129 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

130 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.

131 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, BAUER, C.; KING, G. Hibernate em Ação. Rio de Janeiro: Ciência Moderna, BATES, B.; SIERRA, K. SCJP: Certificação Sun para Programador Java 5. Rio de Janeiro: AltaBooks, BECKER, A. K.; CLARO, D. B.; SOBRAL, J. B. Web Services e XML Um Novo Paradigma da Computação Distribuída 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, DEITEL, H. M. et al. JAVA Web Services for Experienced Programmers. New Jersey: Prentice Hall, 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, Disponível em: < html>. Acessado em: 15 jan HENDRICKS, M. et al. Profissional Java Web Services. Rio de Janeiro: Alta Books, MARQUEZAN, C. C. Estudo das características de serviços Web e de seus cenários de aplicação 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, SOUSA, E. C. Sistema de Informação para uma clínica de acupuntura médica f. Trabalho de Conclusão de Curso (Bacharelado de Informática) - Departamento de Ciências Exatas e da Terra, Universidade do Planalto Catarinense -

132 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: < Acesso em: 15 jan 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: < Acesso em: 15 jan 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: < Acesso em: 15 jan 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: < >. Acesso em: 15 jan 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 < Acesso em: 15 jan 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: < Acesso em: 15 jan 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: < Acesso em: 24 nov 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.

133 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), Apresenta o framework de segurança para Web Services em aplicações Java. Disponível em: < Acesso em: 15 jan. 2006j. UDDI. About UDDI. UDDI.org, Página que explica a funcionalidade do padrão UDDI. Disponível em: < Acesso em: 17 mar W3C. SOAP Version 1.2 Part 1: Messaging Framework. W3C Recommendation, 2006a. Apresenta o framework SOAP e suas especificações. Disponível em: < Acesso em: 17 mar 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: < Acesso em: 17 mar W3C. XML-Signature Syntax and Processing. W3C Recommendation, 2006c. Documento que descreve a especificação de assinaturas digitais em documentos XML. Disponível em: < Acesso em: 17 mar W3C. XML Encryption Syntax and Processing. W3C Recommendation, 2006d. Documento que descreve a especificação de criptografia em documentos XML. Disponível em: < Acesso em: 17 mar WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier: Campus, 2004.

134 BIBLIOGRAFIA COMPLEMENTAR CHAPPELL, D.; IEWELL, T. Java Web Services. Estados Unidos: O Reilly, DEITEL, H. M. et al. XML: como programar. Porto Alegre: Bookman, HADLEY, R. C. M. Next Generation Web Services in the Java Platform. In: JAVAONE CONFERENCE San Francisco /US. Sun Microsystems SUN MICROSYSTEMS. Securing Web Services Concepts, Standards, and Requirements. Santa Clara, Califórnia, Estados Unidos: SUN MICROSYSTEMS 2003.

135 APÊNDICE - ARTIGO SEGURANÇA EM WEB SERVICES COM JAVA... 1

136 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 ¹fernando.parisotto@gmail.com, ²marcosap@uniplac.net 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 e- commerce 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

137 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;

138 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.