Desenvolvimento de uma infra-estrutura para composição dinâmica e segura de Serviços Web 1

Transcrição

1 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 333 Desenvolvimento de uma infra-estrutura para composição dinâmica e segura de Serviços Web 1 Jorge R. Lohn 1, Michelle S. Wangham 1 1 Universidade do Vale do Itajaí Centro de Ciências Tecnológicas da Terra e do Mar Rodovia SC KM4 - Sertão do Maruim São José SC Brasil {jlohn, wangham}@univali.br Abstract. Business Processes describe complex services that transpose the organizational boundaries and are provided by different partners. The dynamic composition of business processes provides flexibility and easy adaptation to changes in the rules of business, and create cohesive and reusable services. To use the dynamic composition, it is necessary an infrastructure that enables secure communication between all participants. This paper describes the security infrastructure for dynamic composition of business processes in collaborative networks geared to services, based on a case study. Resumo. Processos de negócios descrevem serviços complexos que transpassam os limites organizacionais e são providos por diferentes parceiros. A composição dinâmica de processos de negócio proporciona flexibilidade e fácil adaptação às mudanças nas regras de negócio, além de criar serviços coesos e reutilizáveis. Para possibilitar a composição dinâmica, é necessária uma infra-estrutura que possibilite a comunicação segura entre todos os participantes. O objetivo deste artigo é descrever uma infra-estrutura de segurança para composição dinâmica de processos de negócios em redes colaborativas orientadas a serviços, tendo como base um estudo de caso. 1. Introdução Conforme consta em [W3C 2004], os Serviços Web seguem a Arquitetura Orientada a Serviços (AOS) e são componentes de softwares projetados para suportar interações entre aplicações heterogêneas sobre a Internet. A AOS é um paradigma para organização e utilização de competências distribuídas que estão sob controle de diferentes domínios proprietários. Os serviços são independentes de plataforma, de linguagens de programação e arquitetura de máquina, pois utilizam padrões abertos e bastante difundidos, tais como o XML e o HTTP [De Mello et. al. 2006]. No contexto da AOS, a composição de Serviços Web visa criar processos de negócios de alto nível, que transpassem diferentes limites organizacionais [Peltz 2003]. Conforme [Charfi e Mezini 2005], a composição de Serviços Web visa combinar serviços de diferentes provedores a fim de criar um Serviço Web mais sofisticado e com maior valor agregado. Segundo [Milanovic e Malek 2004], desenvolvedores e usuários 1 Trabalho financiado pelo CNPQ (CNPq /2007-5).

2 334 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais podem solucionar problemas complexos a partir da combinação de serviços básicos, em uma ordem conveniente à solução do problema, acelerando o desenvolvimento de aplicações e possibilitando a reutilização de serviços, diminuindo tempo e custo para o desenvolvimento de processos de negócio de alto nível. Através da especificação WS- BPEL é possível criar composição de Serviços Web. A WS-BPEL é a linguagem mais popular e de grande aceitação para a execução de processos de negócio de Serviços Web, a qual define um conjunto de atividades participantes da orquestração, especificando padrões de fluxo de controle e de dados [OASIS 2007]. A composição dinâmica de Serviços Web visa ligar, automaticamente, diferentes serviços a fim de atingir um objetivo complexo, tendo como base, normalmente, dados semânticos adicionais que descrevem os Serviços Web, os quais são utilizados para a geração dinâmica de processos de negócios [Berners-Lee, Hendler e Lassila 2001]. O uso da Web semântica na composição de Serviços Web é um tópico de pesquisa muito relevante devido ao seu potencial em alcançar uma integração de aplicações que seja dinâmica, escalável e com custo efetivo [Wu et al. 2003]. Em muitos casos, as partes que compõem as redes colaborativas não se conhecem e, mesmo em empresas que são parceiras, a segurança sempre é uma preocupação. Devido à necessidade do compartilhamento de informações sigilosas, as redes colaborativas precisam de uma efetiva infra-estrutura de segurança para impedir que um membro consiga acesso não autorizado às informações. Cada empresa que compõem uma rede colaborativa possui suas próprias políticas, logo neste ambiente colaborativo têm-se várias políticas de segurança. Cada domínio transposto por um processo de negócio pode prover seu próprio conjunto de credenciais de segurança, tomando como base suas tecnologias subjacentes de segurança e suas políticas de segurança e de negócios (DE MELLO et al., 2005). Ou seja, havendo a necessidade de colaboração, há ainda a necessidade de um acordo entre os parceiros envolvidos. Este trabalho tem por objetivo descrever uma infra-estrutura para composição dinâmica e segura de processos de negócios em redes colaborativas orientadas a serviços, com base em um estudo de caso (Agência de Viagens). Na Seção 2, são descritas as principais especificações para prover segurança na arquitetura dos Serviços Web. A Seção 3 descreve a infra-estrutura proposta. A Seção 4 descreve o estudo de caso desenvolvido para verificar a aplicabilidade do modelo proposto. Na Seção 5, a implementação de um protótipo da infra-estrutura e do estudo de caso é descrita. Por fim, na Seção 6, os resultados e as contribuições deste trabalho são descritos na conclusão. 2. Segurança em Serviços Web A segurança é sempre uma questão importante em sistemas distribuídos. Vários padrões são utilizados para prover segurança às informações expressas em XML [Imamura et al. 2002; Bartel et al. 2002] e conseqüentemente aos Serviços Web. Entretanto, quando se considera não mais um serviço único, mas sim uma orquestração de Serviços Web, constata-se que a segurança dos processos de negócios não foi ainda profundamente investigada e que ainda não existem soluções concretas e completas [Koshutanski e Massacci 2003; Charfi e Mezini 2005; Carminati, Ferrari e Hung 2005]. As tecnologias desenvolvidas para prover a comunicação segura, a autenticação e autorização precisam ser aprimoradas para que a composição dinâmica ganhe maior confiabilidade.

3 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 335 Nas seções a seguir são apresentadas as principais especificações para prover segurança no ambiente de Serviços Web e alguns trabalhos que visam prover segurança para composições de Serviços Web Especificações de Segurança para os Serviços Web A especificação XML Signature (XMLDSig) [Bartel et al. 2002] foi uma proposta conjunta da W3C e IETF que define regras para gerar e validar assinaturas em XML. Com a XMLDsig é possível assinar documentos XML, bem como qualquer tipo de documento eletrônico. O padrão XML Encryption (XMLEnc) [Imamura et al. 2002] garante a segurança fim-a-fim para aplicações que necessitem realizar a troca de dados de forma segura. Garante a confidencialidade persistente, garantindo assim a confidencialidade dos dados mesmo depois do término da sessão. A especificação Security Assertion Markup Language (SAML) [OASIS 2005] consiste em um conjunto de especificações e esquemas XML, que juntos definem uma forma padrão para criar, trocar e interpretar asserções de segurança entre entidades de uma aplicação distribuída. Por meio de XML, são expressas informações sobre a autorização e atributos de um sujeito. A SAML visa garantir a interoperabilidade entre os diferentes sistemas de autenticação.a WS-Security [OASIS 2006] define um esquema XML (conjunto de extensões ao SOAP) que possibilita incluir de forma padronizada as informações relacionadas à assinatura e cifragem dos dados da mensagem SOAP em questão, utilizando as especificações XMLDSig e XMLEnc para permitir a construção de Serviços Web seguros. A especificação visa garantir a segurança fim-a-fim no nível de mensagem e não somente no nível de transporte [De Mello et al. 2006]. A WS-Policy [W3C 2007] e a WS-PolicyAttachment [W3C 2006] permitem especificar requisitos não funcionais aos serviços ou recursos dentro do ambiente de Serviços Web. A WS-Policy provê uma gramática flexível e extensível, baseada em XML, a qual permite descrever uma ampla variedade de requisitos e habilidades para o ambiente de Serviços Web. A WS-Policy apresenta um modelo dividido em três principais componentes: 1) asserção da política: representa um requisito ou uma qualidade do recurso, específica a um domínio; 2) alternativas de política: é a combinação de asserções de políticas, definindo um conjunto de requisitos para satisfazer tal alternativa; e 3) política: é um conjunto de alternativas de políticas; satisfazer a política significa satisfazer alguma dessas alternativas. A especificação WS- PolicyAttachment provê meios para associar políticas escritas através da WS-Policy com os determinados recursos e também define como associar políticas a elementos XML, no caso dos Serviços Web, os documentos WSDL (Web Service Description Language) e UDDI (Universal Description, Discovery and Integration) Trabalhos Relacionados Conforme constatado em [Charfi e Mezini 2005] são poucos os trabalhos acadêmicos que tratam aspectos de segurança no contexto da composição de Serviços Web. No campo da indústria os esforços são ainda menores. Nenhum esforço concreto, por parte da OASIS, entidade que padroniza a linguagem WS-BPEL, visa promover a aproximação dos grupos de trabalhos desta linguagem com os que trabalham com os padrões de segurança, para indicar como deve ocorrer a interação e integração da camada de processo de negócios com a camada de qualidade de serviço (de segurança).

4 336 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Um dos primeiros esforços para prover segurança em processos de negócios BPEL, proposto em [Koshutanski e Massacci 2003], trata somente de aspectos de autorização, através de um modelo de controle de acesso interativo baseado em abduções lógicas que visa proteger os interesses de segurança dos processos e de seus parceiros. Requisitos como a autenticação SSO (Single Sign On) diante de diferentes tecnologias de segurança e de qualidade de proteção não são cobertos pelo framework. Uma proposta mais ampla para tratar o problema da segurança no contexto das atividades BPEL é descrita em [Charfi e Mezini 2005]. Os autores têm como premissa que a especificação das interações entre Serviços Web dentro de uma composição deve ser acrescida com especificações de propriedades relacionadas à segurança. Este trabalho está baseado no uso da especificação WS-Security para prover a qualidade de proteção das mensagens e do padrão WS-Policy para especificar os requisitos de segurança das atividades BPEL. A lógica necessária para garantir as características de segurança é anexada dentro da lógica de composição usando um conjunto de aspectos. Os aspectos são gerados (em tempo de implantação) a partir de uma biblioteca de aspectos, de acordo com um descritor XML de implantação. De acordo com a solução proposta, os processos de negócios deixam de ser executados quando não há compatibilidade entre os mecanismos de autenticação ou quando não há confiança estabelecida entre os parceiros. A idéia de que tanto os provedores quanto os requerentes possuam preocupações de segurança que devem ser levadas em conta durante a composição dos Serviços Web é amplamente discutida em [Carminati, Ferrari e Hung 2005]. Nesse trabalho, os autores definem uma forma para modelar restrições de segurança que estão em conformidade com os padrões de Serviços Web. Ao invés de utilizar o padrão WS-Policy, este trabalho utiliza uma solução particular para especificar estas restrições. Uma abordagem para implantar a avaliação de compatibilidade entre as restrições de segurança também é definida através de uma arquitetura intermediadora (brokered), em que um serviço (broker) é que executa o processo de casamento de requisitos. Em [Huang 2005], um framework de segurança baseado em políticas usando descrições semânticas de requisitos de segurança é modelado. O framework prevê a especificação de políticas de alto nível, incluindo restrições complexas relacionadas com a lógica de negócio, por meio de descrições semânticas. O modelo está focado na WS-BPEL e prevê a integração de uma definição de processo com as políticas de segurança, no entanto não define como isso deve ser feito, nem como as políticas devem ser especificadas. 3. Infra-estrutura Proposta Para criação de processos de negócios executáveis em redes colaborativas, foi modelada uma infra-estrutura de segurança para composição dinâmica de Serviços Web 2. A infraestrutura pode ser dividida em três partes: a primeira parte da infra-estrutura proposta 1 Este artigo é resultante de um trabalho de conclusão de curso e encontra-se inserido dentro de um projeto mais amplo, intitulado Mecanismos de Segurança para Processos de Negócios em Redes Colaborativas (CNPQ/ Edital Universal 2007). Estudos e trabalhos já foram realizados no contexto deste trabalho, a saber: (1) um modelo de composição de políticas de qualidade de proteção para Serviços Web compostos [Böger 2008]; e (2) Infra-Estrutura de Segurança para Orquestração de Serviços Web em Sistemas Abertos [Carpes 2008].

5 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 337 corresponde ao serviço CompositorPNSeg responsável pela seleção dinâmica dos parceiros do processo de negócio; a segunda parte é responsável por associar às políticas de segurança as trocas de mensagens do processo de negócio, chamado compositor de políticas de qualidade de proteção para Serviços Web compostos [Böger 2008]. A última parte da infra-estrutura de segurança, a camada de segurança, será responsável por aplicar as políticas de segurança geradas pelo compositor de políticas ao processo de negócio [Carpes 2008]. O presente artigo contribuiu através da definição da infra-estrutura e do estudo de caso para validar a infra-estrutura. Conforme ilustrado na Figura 1, na infra-estrutura proposta, um cliente inicia o processo através de uma invocação ao CompositorPNSeg (passo 1 da Figura 1). Nesta invocação, as informações repassadas pelo cliente (dados semânticos) devem estar estruturadas em uma instância de uma ontologia, a qual permite ao cliente especificar de forma não ambígua as informações a serem utilizadas para selecionar os serviços participantes da composição dinâmica. Para cada aplicação específica, é preciso desenvolver uma ontologia e estender as funcionalidades da infra-estrutura. Com base nos dados semânticos, o CompositorPNSeg irá consultar os registros UDDI, localizados em um ou mais diretórios UDDI, a fim de selecionar os serviços que atendam os requisitos expressos e que irão compor o processo de negócio (ver passo 2). O passo 3 ilustra a criação do processo de negócio executável, o qual é criado através da linguagem WS-BPEL, este processo deverá conter chamadas aos métodos de cada um dos serviços que foram selecionados no passo 2. Figura 1. Infra-estrutura de segurança proposta Conforme ilustrado no passo 4, o serviço CompositorPNSeg interage com o serviço compositor de políticas de qualidade de proteção para Serviços Web compostos, obtendo como resultado um conjunto de políticas associadas às trocas de mensagens do processo de negócio, sendo que esse conjunto pode ser entendido como a política composta da colaboração. Segundo Böger (2008), a política composta indica quais os mecanismos de proteção que devem ser utilizados nas trocas de mensagem do processo

6 338 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais e também demonstra se existe algum ponto onde não há compatibilidade dos mecanismos requeridos pelos participantes do processo. Assim sendo, as políticas devem ser descritas e anexadas de acordo com a WS-Policy e WS-PolicyAttachment, as asserções de segurança devem estar de acordo com a WS-SecurityPolicy e os processos de negócio devem ser descritos em WS-BPEL. Caso a política gerada seja nula, o CompositorPNSeg irá recriar o processo BPEL, conforme ilustrado no passo 5 da Figura 1. Ao recriar um processo, o CompositorPNSeg obtêm as interseções que geraram políticas sem alternativa, obtendo desta forma os serviços a serem substituídos. Após substituir os serviços que não possuíam políticas compatíveis, o novo processo deve ser validado novamente para verificar se todas as intersecções possuem políticas válidas. Neste ponto, o processo de negócio já está criado e pronto para ser executado em um motor de orquestração, pois o processo dinâmico já foi criado e a política de segurança já foi anexada. O passo 6 ilustra o retorno do processo BPEL para a aplicação que invocou o CompositorPNSeg. O passo 7 ilustra a execução do processo de negócio no motor de orquestração. Durante a execução do processo BPEL, a camada de segurança intercepta todas as trocas de mensagens entre o processo BPEL e os serviços participantes. É neste momento que as políticas definidas pelo compositor de políticas são aplicadas às trocas de mensagem, tendo como base a especificação WS-Security. O resultado gerado pela execução do processo de negócio é retornado ao cliente como resultado da execução segura do processo composto dinamicamente (ver passo 7). 4. Estudo de Caso A fim de verificar a aplicabilidade do compositor de processos dinâmicos, este foi empregado em um estudo de caso chamado Agência de Viagens. Neste estudo de caso, o agente de viagens é um processo de negócio (orquestração BPEL), resultante do processo de seleção de participantes e de criação do processo de negócio, realizado pelo CompositorPNSeg. A aplicação da agência de viagens oferece meios para consultar informações sobre hotéis, empresas aéreas e locadoras de veículo, disponibilizando desta maneira um mecanismo flexível para criação de pacotes de viagens. Para possibilitar a consulta foi desenvolvida uma ontologia OWL para representar as informações do cliente. Também foram desenvolvidos Serviços Web para representar os hotéis, para representar empresas aéreas e por fim, para representar locadoras de automóveis. Para cada domínio de aplicação (hotel, companhia aérea e locadora), foi desenvolvida uma ontologia, seguindo o padrão OWL-S, para definir quais dados semânticos cada serviço deveria anexar a sua WSDL. Conforme ilustrado na Figura 2, usando um navegador, o cliente, interessado em montar um pacote de viagens, acessa a aplicação web da agência de viagens para poder especificar suas preferências, preenchendo um formulário. Este formulário é enviado a uma aplicação web para que, com base nestas informações, uma instância da ontologia para a agência de viagens seja criada, possibilitando que a aplicação invoque o CompositorPNSeg para selecionar os parceiros mais aptos a fornecer os serviços ao cliente, ou seja, para que o CompositorPNSeg defina o processo de negócio, que será executado para coletar as informações necessárias dos parceiros selecionados, tais como preço e condições de pagamento. Foi necessário o desenvolvimento de uma aplicação web já que o navegador não consegue trocar mensagens SOAP com Serviços Web, logo a aplicação web obtém as informações submetidas, monta a mensagem SOAP e invoca o serviço CompositorPNSeg.

7 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 339 Para definir o processo BPEL, o CompositorPNSeg invoca o método comporprocesso (conforme Figura 2), passando como parâmetro uma instância da ontologia criada para representar as informações das preferências do cliente. O CompositorPNSeg analisa a instância da ontologia recebida com o objetivo de selecionar, em um serviço de diretórios, os serviços com maior aptidão para fornecer as melhores opções para o cliente. Para selecionar os parceiros o método selecionaparceiros é invocado. Em seguida, o CompositorPNSeg, através da invocação do método criaprocessobpel cria o processo BPEL, chamado de AgenteDeViagens, para interagir seqüencialmente com todos os serviços selecionados. Para este estudo de caso, foi definido que dentre a lista de parceiros retornada, o CompositorPNSeg seleciona os três primeiros Serviços Web de cada domínio de aplicação (hotel, companhia área e locadora de automóvel). Figura 2. Estrutura do estudo de caso (Agência de Viagens) Após a criação do processo AgenteDeViagens, o CompositorPNSeg interage com o serviço Compositor de Políticas de Qualidade de Proteção para verificar a compatibilidade das políticas dos serviços integrantes da composição e para gerar a política global do serviço composto. O Compositor de Políticas é um Serviço Web que possui apenas um método composepolicies o qual recebe como parâmetro o processo BPEL do AgenteDeViagens. Se o resultado sumário retornado pelo compositor de políticas for de sucesso, indicando que não há incompatibilidades entre as políticas dos serviços participantes, então o processo AgenteDeViagens já pode ser executado no motor de orquestração. Logo, o processo recém criado é retornado para a aplicação que está interagindo com o CompositorPNSeg. Caso o resultado sumário seja de falha, indicando que há incompatibilidades entre os serviços Web participantes, será necessário então recriar o processo para substituir o serviço que não possui compatibilidade de política. Para solucionar este problema o CompositorPNSeg invoca o método recriaprocessobpel, o qual procura substituir os serviços que apresentaram incompatibilidade de políticas. Se

8 340 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais o CompositorPNSeg não encontrar um serviço que satisfaça os requisitos do cliente e de segurança, então o serviço é eliminado do AgenteDeViagens. Em seguida, a aplicação executa o AgenteDeViagens, através do método consultaparceiros, sendo que este deve ter a propriedade createinstance assinalada. Cada invocação realizada pelo AgenteDeViagens com outros serviços é interceptada pelos interceptadores de mensagem responsáveis por aplicar os mecanismos de segurança. Quando a mensagem é enviada a partir do AgenteDeViagens, o interceptador de mensagem (handler) intercepta a mensagem e aplica a política global, quando um Serviço Web envia uma mensagem, o interceptador de mensagem intercepta e aplica as políticas daquele serviço. Conforme ilustrado na Figura 2, ao término da sua execução, os resultados provindos das invocações aos serviços participantes da composição são retornados à aplicação que invocou o método consultaparceiros do AgenteDeViagens. Por fim, a aplicação web gera uma resposta com as informações obtidas (página HTML) para serem enviadas ao navegador. As informações são exibidas no formato do arquivo XML no navegador do cliente. 5. Implementação A infra-estrutura para composição dinâmica e segura de Serviços Web e o estudo de caso (Agência de Viagens) foram desenvolvidos na plataforma Java e em alguns frameworks open source. A agência de viagens é uma aplicação web que foi desenvolvida utilizando-se da tecnologia JSF 1.2 (JavaServer Faces) 3 com o auxílio de algumas bibliotecas de componentes, como a facelets 4 e tomahawk 5, além de utilizar HTML e CSS (Cascading Style Sheets). Para criar a instância da ontologia com as informações do usuário foi utilizado o framework open source Jena, sendo este um projeto desenvolvido em Java e utilizado para a criação de aplicações web semânticas. Os Serviços Web para representar as empresas aéreas, os hotéis e as locadoras de automóvel foram desenvolvidos com o framework Apache Axis2. O Axis2 é uma plataforma para implementação e interação com serviços Web, o qual está dividido em vários módulos. Nestes módulos, as mensagens são interceptadas através dos handlers. Foi através destes handlers que a política composta foi aplicada às trocas de mensagens. O núcleo da sua implementação é voltado puramente para o processamento de mensagens SOAP, sem nenhum vínculo à camada de transporte destas mensagens, suportando tanto interações síncronas, quanto assíncronas. Para cada serviço foram desenvolvidas políticas de segurança. As políticas foram desenvolvidas com base na especificação WS-Policy. E através da especificação WS-PolicyAttachment, as políticas são anexadas à interface WSDL do Serviço Web e também do processo BPEL do AgenteDeViagens. Para cada serviço desenvolvido foi criada uma instância da ontologia OWL-S para possibilitar o uso de dados semânticos nos Serviços Web, sendo disponibilizadas junto com o Serviço Web que descreve. Cada ontologia que descreve um serviço é 3 O JSF é um framework MVC (Model View Controller), que possibilita uma separação entre as camadas da aplicação, ou seja, garantindo a modularidade. Disponível em: 4 Disponível em: 5 Disponível em:

9 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 341 composta por 4 arquivos, o service que informa onde encontra-se as outras ontologias, o presents que descreve o que o serviço fornece, o supports que descreve como o serviço é acessado e o describedby que descreve como o serviço funciona. A ferramenta ActiveBPEL foi utilizada para escrever a WS-BPEL do compositorpnseg, sendo este implementado em Java e executado no motor de orquestração Apache ODE. Porém, como o compositor de processos segue a especificação WS-BPEL este pode ser executado em qualquer outro motor de orquestração que implementa WS-BPEL. O CompositorPNSeg utiliza o framework Jena para analisar as instâncias das ontologias. Para simplificar a solução, neste trabalho foi feito o casamento sintático das ontologias. Testes de software foram feitos ao longo do desenvolvimento de cada um dos componentes da infra-estrutura e do estudo de caso. 6. Conclusão O presente trabalho descreveu uma infra-estrutura de segurança para composição dinâmica de Serviços Web, cujo objetivo é criar uma orquestração de Serviços Web para atender uma determinada demanda, ou seja, para solucionar um problema específico. Foi criada a demanda de uma agência de viagens para validar o compositor dinâmico de processos. O compositor dinâmico de processos de negócios seguros é um serviço web composto (uma orquestração BPEL) utilizado para criar processos de negócios executáveis com base de dados semânticos anexados aos serviços web participantes (serviços web semânticos). A especificação OWL-S foi utilizada para possibilitar o uso de dados semânticos nos Serviços Web, por isso cada serviço web deve possuir uma instância da ontologia para descrevê-lo. O resultado do CompositorPNSeg é um processo BPEL que deve ser publicado em um container web para ser então invocado. Visando garantir a integridade, confidencialidade e autenticidade dos processos de negócios resultantes, a infra-estrutura de segurança proposta utiliza os principais padrões de segurança para a arquitetura dos Serviços Web, as especificações Ws-Policy, Ws-Security, XML-Signature e XML-Encryption. Contudo, este trabalho, através dos estudos e dos testes realizados, conseguiu mostrar que é possível criar processos dinâmicos que interajam com seus parceiros de forma segura, através da utilização de ontologias para expressar informações relevantes para a criação do processo de negócio. A área de ontologia para Serviços Web pode ser ainda mais explorada e proporcionar bons trabalhos futuros. Referências Bartel, M.; Boyer, J.; Fox, B.; Lamacchia, B.; Simon, E. (2002). XML-Signature Syntax and Processing. W3C. Berners-Lee, T., Hendler, J., Lassila, O. (2001). The semantic web. Scientific American. Böger, D. S. (2008). Um modelo de composição de políticas de qualidade proteção para Serviços Web compostos. Trabalho de Conclusão de Curso (Graduação) - Universidade Federal de Santa Catarina, Florianópolis.

10 342 Anais do IX Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais Carminati, B., Ferrari, E., e Hung, P. C. K. (2005). Web service composition: A security perspective. In Proceedings WIRI, pages Carpes, F. W. M. (2008). Infra-Estrutura de Segurança para Orquestração de Serviços Web em Sistemas Abertos. Projeto de Fim de Curso (Graduação) - Universidade Federal de Santa Catarina, Florianópolis. Charfi, A. e Mezini, M. (2005). Using aspects for security engineering of web service compositions. In Proceedings of the 2005 IEEE International Conference on Web Services, volume I, pages IEEE. De Mello, E. R., Wangham, M. S., Fraga, J. S. e Camargo, E. (2006). Segurança em Serviços Web. In: Jorge Nakahara Jr; Lau Cheuk Lung. (Org.). Livro texto dos Minicursos do VI Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais (SBSeg2006). SBC: Porto Alegre, v. 1, pages Huang, D. (2005). Semantic policy-based security framework for business processes. In: 4th International Semantic Web Conference. Imamura, T., Dillaway, B., Simon, E. (2002). XML Encryption Syntax and Processing. W3C. Koshutanski, H., Massacci, F. (2003). An access control framework for business processes for web services. Proc. XMLSEC '03: Proceedings of the 2003 ACM workshop on XML security. pages Milanovic, N.; Malek, M. (2004). Current Solutions for Web Service Composition. Berlin, Web Services Architecture. OASIS. (2005) Security Assertion Markup Language (SAML) 2.0 : Technical Overview. OASIS. OASIS. (2006). Web Services Security: SOAP Message Security 1.1. OASIS. SOAPMessageSecurity.pdf. OASIS (2007). Web Services Business Process Execution Language Version 2.0. OASIS. Peltz, C. (2003). Web services orchestration and choreography. IEEE Computer, 36(10): pages W3C (2004). Web Services Architecture. W3C. (2006). Web Services Policy Attachment (WS-PolicyAttachment), World Wide Web Consortium. W3C. (2007). Web Services Policy 1.5 Framework. World Wide Web Consortium. Wu, D., Parsia, B., Sirin, E., Hendler, J. e Nau, D. (2003). Automating DAML-S web services composition using SHOP2. Proc. Proceedings of 2nd International Semantic Web Conference (ISWC2003), Sanibel Island, Florida.