Captulo

1
Segurana em Servios Web
Emerson Ribeiro de Mello, Michelle S. Wangham, Joni da Silva Fraga, Edson Camargo Departamento de Automao e Sistemas Universidade Federal de Santa Catarina email:{emerson,wangham, fraga, camargo}@das.ufsc.br

Abstract The use of open standards and integrative nature are features that made Web Services an interesting area to academic research and to industry. This chapter introduces the concepts behind the Service Oriented Architecture, Web Services, in particular. This text shows, through a use case, the benets of this architecture and its security challenges. Afterwards, we present some research projects and technologies that deal with these security challenges. Resumo Devido a sua caracterstica integradora e por fazer uso de padres abertos, os Servios Web se tornaram uma rea de grande interesse para pesquisa e para a indstria. Neste captulo, pretende-se introduzir ao leitor os conceitos da arquitetura orientada a servios, e em particular, a sua mais atual caracterizao, os Servios Web. Ser mostrado, atravs de um cenrio de uso, os benefcios em utilizar tal tecnologia e tambm sero apresentados os desaos de segurana associados a esta. Por m, so apresentados alguns trabalhos de pesquisa e tecnologias voltadas para tratar tais desaos de segurana.

1.1. Introduo
H tempos que a Internet se consolidou como um importante veculo de comunicao e no demorou muito para se tornar uns dos principais meios para a realizao de negcios. A Internet tambm conhecida por agregar os mais diversos sistemas computacionais que variam desde a arquitetura de mquina, sistema operacional at os aplicativos nais aos usurios. O sucesso deste ambiente to heterogneo foi possvel devido ao uso de protocolos padronizados, que garantem a interoperabilidade entre as aplicaes, no importando em qual sistema operacional ou arquitetura de mquina esta esteja rodando. A Internet surgiu diante de empresas que j faziam uso de seus sistemas computacionais e que, geralmente, no foram desenvolvidos para serem interoperveis, por exemplo, com os sistemas computacionais de seus clientes, fornecedores, etc. Diante da necessidade da interao entre as aplicaes distribudas de diferentes organizaes, uma nova caracterizao de sistemas distribudos surgiu possibilitando assim a troca de informaes e a integrao com os sistemas legados existentes - os Servios Web. Os Servios Web seguem uma Arquitetura Orientada a Servios (AOS) e as principais caractersticas que os tornam uma tecnologia integradora e promissora so: (1) possuem um modelo fracamente acoplado e transparente que garante a interoperabilidade entre os servios, sem que estes necessitem ter o conhecimento prvio de quais tecnologias esto presentes em cada lado da comunicao; (2) so auto-contidos e auto-descritivos; (3) usam padres abertos como o HTTP e o XML, permitindo assim que aplicaes sejam integradas atravs de linguagens e protocolos amplamente aceitos, e (4) tornam mais fcil a composio ou a combinao de diferentes provedores, visando formar servios mais complexos e sosticados. Para a realizao de negcios atravs da Internet, por onde circulam informaes importantes para as corporaes e, muitas vezes, sigilosas, garantir a segurana das informaes uma necessidade crtica. Com os Servios Web, as aplicaes tornam-se mais visveis, expondo assim seus uxos de negcio, processos e arquiteturas internas. Mecanismos de segurana esto sendo propostos para Servios Web, porm, tais mecanismos ainda no contemplam todas as necessidades exigidas para segurana em Servios Web e alguns so propostas iniciais que ainda no se consolidaram como um padro de fato. Este cenrio torna esta rea um excelente ambiente para pesquisa. O objetivo deste captulo analisar as questes de segurana provenientes da adoo de Servios Web, discutir os principais padres que visam minimizar as ameaas que esta tecnologia est suscetvel, bem como apresentar algumas questes de pesquisa em aberto ou que esto sendo atualmente exploradas pelas instituies de pesquisa, que tratam da segurana em Servios Web. O presente captulo est dividido em sete sees. Nesta primeira seo foi descrito o contexto geral em que o trabalho est inserido, destacando os objetivos do documento e a motivao para a escolha do tema. A seo 1.2 introduz os conceitos e as caractersticas da Arquitetura Orientada a Servios e, em seguida, a seo 1.3 apresenta a arquitetura dos Servios Web, com os padres que formam a sua base. Os principais conceitos relacionados com segurana de informao, as questes de segurana em Servios Web e as principais especicaes que objetivam tratar parte destas questes so analisados na

seo 1.4. Na seo 1.5, as questes de segurana no tratadas nas especicaes so discutidas e alguns trabalhos que visam tratar destas questes so analisados. As ferramentas que, atualmente, podem ser para o desenvolvimentos de Servios Web seguros so apresentadas na seo 1.6. Por m, a seo 1.7 apresenta a concluso do captulo, destacando os principais aspectos da segurana em Servios Web que serviram e serve de motivao para pesquisas nesta rea.

1.2. Arquitetura Orientada a Servios

Segundo [Papazoglou 2003], a Arquitetura Orientada a Servios (AOS) (Service Oriented Architecture SOA) uma caracterizao de sistemas distribudos, em que as funcionalidades do sistema so expostas via descrio de uma interface, permitindo a publicao, localizao e a invocao por meio de um formato padronizado. A AOS constituda de relaes entre trs tipos de participantes: o diretrio para registro de servios, repositrio que utilizado para publicar e localizar as interfaces dos servios; o provedor de servios, entidade responsvel por publicar as interfaces dos servios providos por esta no registro de servios e tambm responsvel por atender as requisies originadas pelos clientes; e o cliente, aplicao ou um outro servio que efetua requisies a um servio. Cada participante da arquitetura pode ainda assumir um ou mais papis, podendo ser por exemplo, um provedor e um cliente de servios.
Descrio do servio

Registro de servios Localizar

Publicar
Descrio do servio

Cliente

Invocar

Provedor de servios Servio

Figura 1.1. Interao entre entidades da AOS

Os participantes se relacionam atravs de trs operaes: publicar, localizar e invocar, como pode ser visto na Figura 1.1. Inicialmente, o provedor de servio publica a interface do seu servio junto ao diretrio para registro de servios. Desta forma, em algum momento posterior, o cliente pode efetuar uma busca por um determinado servio (operao localizar), especicando as caractersticas desejadas, no diretrio de registros. Se o servio existir, a interface e a localizao do respectivo servio so retornados para o cliente. Por m, o cliente efetua uma invocao ao provedor do servio (operao invocar). Os servios esto baseados nas trocas de mensagens entre os provedores e os clientes, sendo assim, as mensagens seguem um formato padro, garantindo aos servios a neutralidade da tecnologia e permitindo que provedores e clientes utilizem diferentes implementaes nas camadas inferiores. Os servios tambm so denidos como fracamente acoplados, isso indica que possuem uma localizao transparente e que no necessitam conhecer as estruturas internas presentes no lado do provedor e do cliente.

As interfaces dos servios so auto-descritivas e baseadas em padres abertos. Ou seja, a interface de um servio dene um conjunto de mtodos pblicos, juntamente com seus parmetros, valores de retorno e meios para tratar possveis excees, porm no prov uma implementao. Com isto, pode-se assumir que a interface um contrato entre o provedor do servio e o cliente, sendo que o provedor dever implementar todos os mtodos ali descritos e o cliente s poder invocar tais mtodos. Por estarem relacionados diretamente s funes de negcios, os servios representam uma forma de modularidade diferente daquelas existentes nas linguagens de programao como os mdulos, componentes e objetos. Componentes representam entidades e regras de negcio, j um servio representa uma funo de negcio completa, sendo composto por uma coleo de componentes. Servios podem ser reutilizados e empregados em novas transaes, na camada de negcios, dentro de uma organizao ou atravs de organizaes.

1.3. Arquitetura dos Servios Web

Os Servios Web (Web Services WS) so classicados como um tipo especco de servio, o qual identicado atravs de um identicador uniforme de recursos (Uniform Resource Identier URI). Estes so independentes de linguagens de programao, de sistemas operacionais e das arquiteturas de mquinas. Atravs do uso de padres abertos, como o XML e o HTTP, os Servios Web conseguem garantir a interoperabilidade entre clientes e provedores de servios, sem que os mesmos necessitem possuir o conhecimento prvio de quais tecnologias esto presentes em cada lado. Tal facilidade ideal para que as relaes de negcios entre empresas (Business to Business B2B) sejam estabelecidas de maneira simples e dinmica. A denio para os Servios Web dada em [W3C 2004a] : Trata-se de uma aplicao identicada atravs de uma URI, que possui interfaces bem denidas e descritas em XML. As interaes com outras aplicaes se faz atravs de trocas de mensagens XML utilizando protocolos padres da Internet. Um ponto importante a ressaltar que os Servios Web no so um outro tipo de objetos distribudos, como aqueles presentes no CORBA1 , DCOM2 e RMI3 [OMG 2002, Brown e Kindel 1996, Sun 2002]. Em [Vogels 2003] apresentada uma discusso sobre as semelhanas e diferenas entre Servios Web e sistemas de objetos distribudos. Para Vogels, os Servios Web so um tipo de tecnologia de sistemas distribudos que vem sendo utilizada em reas em que as aplicaes de objetos distribudos falharam no passado. As tecnologias de objetos distribudos e de Servios Web at possuem algumas caractersticas em comum, tais como: uma linguagem para descrio de interfaces (Interface Denition Language IDL), que garante interaes de rede bem denidas; e, mecanismos semelhantes para registro e localizao de objetos ou servios. Entretanto,
1 Common

Object Request Broker Architecture Component Object Model 3 Remote Method Invocation
2 Distributed

nos sistemas de objetos distribudos, existe o conceito de referncia de objetos, que no existe para os Servios Web. A noo de referncia de objetos essencial dentro de um sistema de objetos distribudos, visto que objetos, geralmente, possuem referncias para outros objetos, possibilitando assim a computao com manuteno distribuda de estado . Todavia, a principal diferena entre os Servios Web e os objetos distribudos o ciclo de vida dos mesmos. Um ciclo de vida de um objeto composto pelas seguintes fases: diante de um pedido, uma fbrica cria uma instncia de um objeto; o cliente que requisitou o pedido, executa operaes no objeto instanciado; por m, em algum momento posterior, o cliente remove a instncia do objeto que no ser mais utilizado. Os Servios Web no possuem um ciclo de vida com caractersticas como: objetos, referncias e fbricas. Servios Web no conseguem oferecer qualquer facilidade para manter estado na computao distribuda, caracterstica bsica de um sistema de objetos distribudos. A arquitetura dos Servios Web tambm no dene relaes entre as invocaes realizadas em um mesmo servio ou ainda em servios relacionados, porm j esto sendo lanadas propostas para permitir tal interao, como a WS-Coordination [Cabrera et al. 2004]. Ambientes, como uma rede local, so caracterizados pela homogeneidade de plataforma e por possurem um tempo de latncia conhecido. Segundo [Vogels 2003], tal tipo de ambiente ideal para a tecnologia de objetos distribudos, visto que uma tecnologia madura e, dentro de tal ambiente, bem robusta. Em ambientes como a Internet, em que a interoperabilidade e o suporte para plataformas e redes heterogneas so essenciais, os Servios Web demonstram ser os mais adequados. A adoo dos Servios Web no implica uso de qualquer aplicativo adicional no cliente ou no servidor. Para o cliente, basta uma linguagem de programao que d suporte a XML e ao HTTP, por exemplo. Tal caracterstica dene os Servios Web como auto-contidos. Servios Web tambm so denidos como auto-descritivos, j que tanto o cliente como o servidor s precisam se preocupar com o formato e com o contedo das mensagens a serem trocadas, abstraindo assim os detalhes de implementao (fraco acoplamento). A arquitetura dos Servios Web composta basicamente por quatro elementos [Vogels 2003]: servio: um aplicativo apto para processar documentos XML recebidos atravs de uma combinao de protocolos de transporte e de aplicao. Detalhes de como esse componente construdo, como tcnicas de orientao a objetos, etc., no so especicados. O nico requisito necessrio para este tipo de componente, que o mesmo esteja apto a tratar documentos XML; endereo: combinao entre protocolo e endereo de rede, utilizada para que um cliente possa acessar um servio; documento XML: um documento que contm informaes especcas aplicao;

 envelope: encapsulamento que garante que documentos XML sejam processados de forma correta, separando as informaes relacionadas a comunicao dos dados em si. Por exemplo, informaes relacionadas a forma como a mensagem ser cifrada ou assinada podem ser especicadas em um envelope sem que o documento XML original seja modicado. Para tornar possvel as trs operaes fundamentais de uma AOS - publicar, localizar e invocar - a arquitetura de Servios Web adota as seguintes tecnologias baseadas em XML: a Web Services Description Language (WSDL)[W3C 2001], linguagem padro usada para descrever as funcionalidades dos Servios Web; o Universal Description, Discovery and Integration (UDDI) [OASIS 2004b], servio padro para publicao e localizao de Servios Web; e o SOAP [W3C 2003], protocolo usado para a invocao do servio.
2. Consulta 3. Obtm a descrio do servio WSDL UDDI 1. Publica WSDL

Cliente

4. Efetua a invocao

Servio Web

Figura 1.2. Colaborao tpica na Arquitetura dos Servios Web

A Figura 1.2 ilustra uma colaborao tpica da arquitetura dos Servios Web. O processo para tornar um Servio Web publicamente disponvel requer, inicialmente, que o provedor de servios descreva a interface do servio que deseja prover, utilizando a WSDL, e em seguida publique a interface em um servio de busca pblico, como por exemplo o UDDI (passo 1 da Figura 1.2). A partir de ento, o cliente pode localizar o servio desejado e obter a sua WSDL (passos 2 e 3). A comunicao entre o provedor e o consumidor de um servio realizada atravs de trocas de mensagens XML, encapsuladas dentro de envelopes SOAP (passo 4). A seguir, uma breve descrio das tecnologias empregadas na arquitetura dos Servios Web apresentada. 1.3.1. WSDL A Web Services Description Language (WSDL) [W3C 2001] uma gramtica em XML, extensvel, para especicar interfaces de Servios Web. Um documento WSDL independente de linguagem e de plataforma e tem por objetivo: (1) descrever quais so os servios oferecidos; (2) mostrar como os clientes e provedores iro processar as requisies; e, (3) indicar em qual formato o servio deve enviar as informaes para um cliente. Segundo [Weerawarana et al. 2005], um documento WSDL composto por uma parte abstrata, que descreve o que o Servio Web faz em termos de mensagem que este consome e produz, e por outra parte concreta que referente a implementao e que dene como e onde o servios oferecido. Os principais elementos XML presentes em um documento WSDL so:

 types: dene os tipos de dados, utilizando o XML Schema Denition (XSD) ou ainda algum outro mecanismo para denio de tipos; message: dene, de forma abstrata, as mensagens que sero trocadas; operation: dene, de forma abstrata, a operao para uma mensagem; portType: descreve um conjunto abstrato de operaes mapeadas para um ou mais servios, os quais so descritos como pontos nais de rede ou portas; binding: especica como mapear os elementos abstratos, message e operation, nos protocolos de rede que sero utilizados para transportar as mensagens at o destino (suas representaes concretas); port: uma combinao entre o elemento binding e o endereo de rede, provendo assim um endereo nico para acessar um servio; service: declara o endereo das portas para os bindings. Ou seja, indica onde encontrar um servio usando sua porta. Os quatro primeiros elementos pertencem parte abstrata da WSDL e os quatro ltimos, parte concreta. Cada um destes elementos pode ser descrito em diferentes documentos XML, e a combinao de todos estes formam uma descrio completa de um Servio Web. A independncia dos elementos principais traz uma grande exibilidade para a disponibilizao dos servios. Uma mesma descrio de tipos de dados pode ser utilizada por diversos Servios Web ou ainda mltiplos meios de transporte podem estar disponveis para um servio. A WSDL uma linguagem exvel que tambm permite a incluso de elementos no denidos pela especicao, possibilitando assim representar os atuais e os futuros formatos de mensagens. 1.3.2. UDDI A especicao do Universal Description, Discovery and Integration (UDDI) [OASIS 2004b] dene uma forma padronizada para publicao e descoberta de servios dentro da Arquitetura Orientada a Servio (AOS), que parte fundamental na pilha de protocolos dos Servios Web. A implementao de um servidor UDDI composta por diversos Servios Web, que provem uma interface para que os clientes possam ter acesso as informaes ali armazenadas. Os dados e meta-dados dos Servios Web so armazenados em diretrios UDDI (UDDI registry), associando a cada estrutura de dados um identicador nico, denominado UDDI key, criado de acordo com regras de classicao especicadas por cada organizao. Tal classicao permite aos consumidores realizarem consultas mais renadas, permitindo, por exemplo, buscar por provedores que forneam determinado servio dentro de uma localizao geogrca especca. Os diretrios UDDI no armazenam somente informaes relativas a implementao de um Servio Web, como a WSDL do servio, estes tambm podem armazenar informaes relacionadas diretamente a entidade que prov o servio. O modelo de dados UDDI prev os seguintes tipos de dados: businessService, descries sobre a funes de negcio de um servio; businessEntity, informaes sobre a organizao detentora do

servio; bindingTemplate,informaes tcnicas do servio, como por exemplo, endereo para invocao do mesmo; e, tModel, outros atributos, tais como taxonomia geogrca ou industrial. Nas especicaes mais recentes do UDDI [OASIS 2002, OASIS 2004b], foram introduzidos dois novos tipos de dados voltados para a aliao de registros, sendo estes: publisherAssertion e subscription [OASIS 2004a]. 1.3.3. SOAP Os Servios Web adotaram diversas propostas para realizar trocas de mensagens entre clientes e provedores de servios, mas foi o protocolo SOAP4 [W3C 2003] que surgiu como padro de fato. Denido pelo consrcio W3C, o SOAP um protocolo de comunicao baseado em XML para a troca de mensagens, independente de linguagem, que trabalha com diversos sistemas operacionais e sobre protocolos de aplicao j consolidados, como o HTTP, o SMTP, o FTP, o RMI/IIOP, etc. O uso do SOAP sobre o protocolo HTTP se tornou comum nas atuais implementaes de Servios Web devido s facilidades providas pelo HTTP. Entre estas destacam-se: a infra-estrutura j existente dos servidores HTTP para disponibilizar os servios e a facilidade em atravessar os limites de segurana impostos pelos rewalls, tendo em vista que o acesso porta 80, utilizada por servidores HTTP, geralmente liberada nestes mecanismos. Uma mensagem SOAP um documento XML que dene o elemento envelope como sendo o elemento raiz do documento. O envelope SOAP contm as declaraes dos espaos de nomes XML a serem utilizados, bem como as informaes de codicao para a representao dos dados no documento e composto pelos elementos header e body. O header um elemento opcional que contm informaes, dividas em blocos, sobre como a mensagem dever ser processada. Essas informaes podem ser denies de roteamento, asseres de autenticao e autorizao, entre outras. J o elemento body obrigatrio e contm a mensagem em si. Qualquer tipo de informao que puder ser expressa em XML poder fazer parte do corpo da mensagem. Dentro do elemento body pode estar contido o elemento fault, que usado para transportar informaes sobre erros que possam vir a ocorrer no processamento das mensagens. 1.3.4. Uma Aplicao Exemplo Um caso interessante para o uso dos Servios Web o de portal de informaes. Um portal tem por objetivo agregar informaes provenientes de diferentes origens em uma nica e simples interface, se tornando um meio de fcil acesso para os usurios do sistema. Em [Wege 2002] so apresentadas algumas denies para portais, em que possvel destacar duas destas: os portais pblicos e os portais corporativos. Os portais pblicos so, geralmente, denidos por stios que visam reunir informaes de diferentes origens e aplicaes, oferecendo uma interface padronizada e personalizvel para seus usurios. Os portais corporativos tambm renem informaes em uma interface padronizada, porm as informaes ali reunidas s dizem respeito s necessidades da empresa em questo.
sua criao, SOAP era um acrnimo para Simple Object Access Protocol, porm na verso 1.2 tal denio foi descartada pelo W3C, por achar que a mesma era equivocada. Assim, hoje SOAP simplesmente o nome do protocolo e no mais um acrnimo.
4 Em

Os portais de informaes passaram por diversas evolues desde o seu surgimento na dcada de 90, quando se resumiam em diretrios e mquinas de busca para catalogar stios Web, at a mais atual verso que faz uso da tecnologia Really Simple Syndication (RSS) [RSS 2005]. O uso do RSS trouxe facilidades para provedores de informaes e principalmente para os portais, pois apresenta uma forma padronizada e simples para disponibilizar resumos de informaes. Tal tecnologia se constitui em um servio de publicao e assinatura de notcias, porm no permite aos portais agregadores de notcias uma maior interatividade com seus usurios. Os Servios Web podem ser utilizados para a construo de um mesmo de tipo portal que hoje faz uso do RSS. Os provedores de servios web disponibilizam uma interface de servio padronizada para o fornecimento de informaes para os portais e tais interfaces so publicadas em servios como o UDDI. Desta forma, os clientes dos portais recorrem ao servio UDDI para localizar as informaes desejadas, assinando assim os respectivos servios.Com os Servios Web possvel obter um nvel maior de interao entre todas as entidades participantes, seja um cliente interagindo com os provedores de servios, ou seja estes ltimos interagindo entre si. O exemplo a ser apresentado neste captulo consiste de um portal de informaes voltado para o entretenimento. O objetivo do portal reunir em uma nica interface diversos provedores de servios que tenham como rea de atuao o entretenimento pessoal, como por exemplo, cinemas, parques de diverso, vdeo locadoras, teatros, etc. O portal tambm reunir provedores de informaes que no esto diretamente ligados ao entretenimento, mas que servem de base de apoio para a tomada de decises dos usurios deste portal, como por exemplo, stio de previso do tempo, de resenhas de lmes, de companhias areas, de hotis, de operadores de telefonia celular, etc. Inicialmente, assim como a maioria dos servios deste gnero, o portal exige um cadastro por parte de seus usurios, para que estes forneam suas informaes pessoais como nome, endereo, idade, sexo, etc. Aps esta etapa, um usurio pode selecionar os provedores de servios de sua preferncia e assim congurar sua pgina pessoal no portal. Se for o caso, o usurio pode ainda indicar suas preferncias para cada servio selecionado. Por exemplo, no servio de cinema, um usurio poder informar os seus gneros de lmes preferidos, o melhor dia da semana e horrio, para ir ao cinema, etc. Em uma consulta, as informaes retornadas podem ser ainda mais adequadas ao perl do usurio se o servio do cinema tambm souber a cidade e o bairro onde o usurio vive, sua faixa etria, podendo assim indicar ao usurio quais os cinemas mais prximos que esto exibindo os seus lmes prediletos. Este cenrio totalmente possvel de ser implementado quando se considera o ambiente dos Servios Web. O servio do cinema pode requisitar tais informaes do usurio ao servio de cadastro de usurios do portal, tendo em vista que ambos os servios j possuem um acordo rmado para o compartilhamento de informao, acordo este que o usurio tambm possui cincia. A Figura 1.3 ilustra os relacionamentos entre os usurios, o portal e os provedores de servios. A listagem de lmes fornecidas pelo servio do cinema j pode, por exemplo, vir acompanhada com a resenha de cada lme, informao esta obtida atravs da interao do servio do cinema com o servio de um stio especializado em lmes. Enm, com os

Servios

Portal

Servios

Servios

Figura 1.3. Portal de informaes

Servios Web, surge um novo tipo de interao, agora so aplicaes se relacionando com aplicaes sem a necessidade da interveno dos usurios. Nesta seo, preocupou-se em mostrar as facilidades que os Servios Web podem trazer s aplicaes de portais. Porm, sabe-se das inmeras diculdades e implicaes associadas ao uso de Servios Web neste domnio de aplicao. Este captulo se resumir em analisar os principais problemas relacionados segurana computacional por trs desta aplicao de portal de informaes.

1.4. Segurana em Servios Web

Esta seo se inicia com uma breve introduo segurana computacional, para que em seguida as questes e implicaes de segurana relativas ao uso de Servios Web possam ser adequadamente discutidas. Por m, as principais especicaes e trabalhos de segurana direcionados ao ambiente dos Servios Web so descritos e analisados nesta seo. 1.4.1. Conceitos fundamentais de segurana A segurana vista como uma qualidade de servio que garante o fornecimento do servio, mesmo diante de aes de indivduos no autorizados no sistema, sem que ocorram violaes de segurana. Segundo [Russell e Gangeni 1991, Amoroso 1994], a segurana est fundamentada em quatro propriedades que devem ser garantidas: condencialidade: a informao s deve ser revelada para usurios autorizados a acess-la; integridade: a informao no poder ser modicada, intencionalmente ou acidentalmente, por usurios que no possuam direito para tal; disponibilidade: o uso do sistema no poder ser negado, de forma maliciosa, a usurios autorizados; autenticidade: o acesso ao sistema s dever ser feito por usurios autnticos. Algumas literaturas, como em [Landwehr 2001], tambm citam o no-repdio como uma propriedade de segurana. O no-repdio assegura que um usurio no poder

negar a sua participao na ocorrncia de um evento ou transao. As violaes de segurana ocorrem devido explorao das vulnerabilidades existentes nos sistemas. As vulnerabilidades em sistemas computacionais sempre estiveram presentes. Um erro de programao, um erro de congurao ou mesmo um erro de operao, podem permitir que usurios no autorizados entrem no sistema ou mesmo que usurios autnticos executem aes no autorizadas, podendo assim comprometer o funcionamento correto do sistema [Bishop e Bailey 1996]. Uma ameaa consiste em uma possvel ao que, se concretizada, poder produzir efeitos indesejados ao sistema, comprometendo a condencialidade, a integridade, a disponibilidade e/ou a autenticidade. J o ataque a concretizao de uma ameaa, atravs da explorao de alguma vulnerabilidade do sistema, executado por algum intruso de forma maliciosa ou no. As quatro categorias de ataques, normalmente, identicados em sistemas distribudos so: interceptao: uma parte no autorizada obtm acesso informao (revelao no autorizada de informao); interrupo: o uxo normal da mensagem interrompida, impossibilitando que a informao chegue ao destino (negao de servio); modicao: uma parte no autorizada modica a informao recebida da origem e a transmite para o verdadeiro destino (modicao no autorizada da informao); personicao: entidade no autorizada transmite uma mensagem maliciosa pela rede, se passando por uma parte autntica. Em sistemas computacionais, as ameaas so constantes e uma maneira de evitar os ataques identicar e corrigir as vulnerabilidades existentes nos sistemas, algo que no to simples quanto parece. Sistemas mais complexos tendem a possuir mais brechas de segurana, porm so nesses sistemas que a segurana mais enfatizada, sabendo que o comprometimento desses sistemas gerariam enormes prejuzos nanceiros. A poltica de segurana de um sistema um conjunto de diretrizes, normas e procedimentos, os quais estabelecem os limites de operao dos principais5 . A poltica de segurana concebida sob medida para um sistema especco, visto que cada sistema pode possuir diferentes necessidades. As diretrizes ditadas em uma poltica de segurana indicam o que cada componente do sistema (usurios, mquinas, etc) pode ou no pode fazer. As normas indicam o que cada componente est habilitado a fazer e como dever ser feito. As polticas de segurana de sistemas diferem em trs ramos: a segurana fsica, objetiva proteger o meio fsico em que opera o sistema (ex: imposio de restries de acesso a determinadas reas da empresas, medidas contra desastres, etc.); a segurana
universal que o termo principal identique usurios, processos ou mquinas atuando em nome dos usurios de um sistema, que so considerados aptos pela poltica estabelecida (poltica de segurana lgica) em suas aes no sistema. Em contrapartida, usurios, processos e mquinas no autorizados pelas polticas so identicados como intrusos.
5

gerencial, que se ocupa com o ponto de vista organizacional, denindo processos para criao e manuteno das prprias polticas de segurana; e, a segurana lgica, que dene quais usurios tero direitos de acesso ao sistema e quais os direitos que cada usurio possuir. 1.4.2. Principais Questes de Segurana em Servios Web Os Servios Web permitem que as aplicaes se comuniquem sem a necessidade de qualquer tipo de interao com o usurio nal. Voltando ao exemplo da Seo 1.3.4, o portal de entretenimento fornece aos seus usurios a opo para comprar ingressos para shows e ainda permite que o usurio utilize a mesma interface para comprar bilhetes areos e at mesmo para fazer a reserva em um hotel na cidade onde ir ocorrer o show. Neste caso, o usurio est interagindo diretamente com o portal e este, por sua vez, estaria interagindo com os demais sistemas, mediando assim a comunicao dos usurios com os sistemas da companhia area e do hotel. O problema aqui est em como garantir que as informaes do usurio cheguem at o sistema da empresa area ou do hotel de forma segura, visto que as informaes sensveis do usurio, que s interessam a estes sistemas, estariam sendo roteadas e disponveis pelo sistema do portal em si. O roteamento entre mltiplos Servios Web comumente utilizado para obter escalabilidade e tambm para agir como uma ponte entre diferentes protocolos. Tecnologias como o TLS/SSL [Dierks e Allen 1999, Freier et al. 1996] permitem garantir a condencialidade entre duas partes, porm no proporcionam segurana m-a-m, uma vez que a mensagem, para atingir o destinatrio nal, passa por diversos ns intermedirios a nvel de aplicao. Se a cifragem for empregada somente na camada de transporte, ns intermedirios tero reveladas as informaes que passam por eles, de forma proposital ou atravs das lacunas existentes entre uma sesso segura e outra. As lacunas de segurana no ocorrem no transporte dos dados, mas sim quando os mesmos esto disponveis nos ns intermedirios. Assim, as informaes condenciais presentes nas mensagens SOAP, que deveriam permanecer condenciais durante todo o percurso atravs dos ns SOAP intermedirios, poderiam car expostas. Para tratar tal desao, princpios de segurana devem ser aplicados em um contexto de segurana, que inclui muito mais que uma simples troca de mensagens SOAP. A Figura 1.4 ilustra diferentes contextos de segurana, em que o 1o contexto representa uma congurao ponto a ponto e o 2o uma congurao m-a-m.
2 Contexto de segurana 1 Contexto de segurana Roteador SOAP Pedido Resposta Roteador SOAP Pedido Resposta Servio Web

Figura 1.4. Contextos de segurana [IBM e Microsoft 2002]

Um outro desao como garantir os limites de segurana, antes determinados pelos rewalls. Os ltros de pacotes tradicionais se ocupam basicamente com a segurana na camada de rede, analisando se o pacote vem de uma origem convel, porm no se

preocupa com o contedo dos pacotes. Assim, toda e qualquer requisio a um Servio Web ir transpor o rewall. Os Servios Web tambm esto suscetveis a tipos de ataques j conhecidos como negao de servio, mensagens antigas, estouro de pilha, entre outros, conforme apresentado nos trabalhos [Westbridge 2003, Demchenko et al. 2005]. Para garantir a segurana neste novo tipo de ambiente, novos mecanismos de segurana devem ser implantados tambm nas camadas superiores da pilha TCP/IP e devem operar em conjunto com os mecanismos presentes nas camadas inferiores (veja Figura 1.5).
Protocolos de aplicao (XML, HTML) Protocolos de transporte
Filtros de rede tradicionais Ferramentas de segurana

(HTTP, SMTP, JMS, IIOP) TCP/IP

Figura 1.5. Segurana nas diferentes camadas

As interfaces dos Servios Web so complexas e heterogneas e comum um Servio Web, atravs de suas operaes, acessar outros Servios Web. A preocupao da negao de servio que estava diretamente ligada ao stio que hospeda o servio, deve agora ser ampliada. Por exemplo, para uma instncia de um Servio Web perfeitamente cabvel atender 1000 requisies por segundo, porm essa instncia pode fazer uso de servio de terceiros, que para estes, o envio de mais de 10 requisies por segundo pode ser compreendido como um ataque de negao de servio e assim interromper a comunicao. Ao analisar o ambiente apresentado na aplicao exemplo da Seo 1.3.4, possvel notar que para a realizao de um uxo de negcio, a composio de diferentes Servios Web se faz necessrio. Quando se considera no mais um servio nico, mas sim uma orquestrao ou coreograa de Servios Web, constata-se que a segurana dos processos de negcios no foi ainda profundamente investigada e que ainda no existem solues concretas e completas [Char e Mezini 2005]. Na aplicao exemplo, dito que o usurio s precisa se cadastrar no portal, fornecendo suas informaes pessoais, para que estas sejam propagadas por todos os servios participantes. Como os limites administrativos precisam ser transpostos, as aplicaes estaro sob diversos modelos administrativos e de segurana. Cada domnio transposto por um processo de negcio pode prover seu prprio conjunto de credenciais de segurana, tomando como base suas tecnologias subjacentes de segurana e suas polticas de segurana e de negcios. Por exemplo, em um determinado domnio, os usurios so autenticados atravs de um identicador nico e senha; j em outro domnio parceiro, uma Infra-estrutura de Chave Pblica (ICP) usada para este m. Para cada sistema, o cliente dever possuir uma identidade e associada a esta diversos atributos de autorizao. Para o cliente o gerenciamento de tais informaes pode se tornar muito custoso, visto que vai ter que gerenciar diferentes bases, fornecendo geralmente sempre as mesmas informaes e ainda tendo que se preocupar em guardar os diferentes nomes de usurios e senhas. J para os provedores de servio, alm da preocupao de ter que gerenciar in-

meras identidades e credenciais, ser necessrio se preocupar tambm com a poltica de segurana que rege o sistema. Neste caso, a evoluo das polticas um fator que deve ser considerado, sabendo que uma poltica esttica pode cobrir as necessidades de segurana de um determinado momento, porm pode j no conseguir suprir as necessidades que ainda estaro por vir. Assim, o provedor de servio dever considerar a necessidade da evoluo de polticas, sabendo que tal ato no dever desonrar as transaes que esto em andamento, respeitando as polticas estabelecidas naquele momento. Apesar de j existirem esforos para a denio de uma linguagem comum para expressar polticas, como a WS-Policy [WS-Policy 2004], ainda no existe nada padronizado para garantir a coeso destas polticas presentes em diferentes domnios. Em ambientes compostos por um nmero pequeno e conhecido de entidades, o gerenciamento das polticas de segurana no chega a ser um problema. Uma vez denida as polticas possvel que as mesmas continuem vlidas por um longo perodo de tempo, visto que as entidades so conhecidas, bem como as tecnologias de segurana presentes no ambiente. J os ambientes de larga escala, que so conhecidos pela sua dinmica, apresentam o ingresso e egresso constante de entidades e ainda o uso de diferentes tecnologias de segurana. A gerncia das polticas de segurana e a garantia de que as mesmas sero aplicadas so os grandes desaos em ambientes de larga escala. Com o uxo de negcios ultrapassando diversos domnios administrativos, a privacidade dos usurios tambm um assunto que merece ateno. Em um cenrio ideal, os usurios poderiam exercer o direito de determinar como suas informaes sero manipuladas, indicando quais informaes podem ser compartilhadas com terceiros, como esse compartilhamento deve ser feito e tambm indicando o perodo de tempo que essas informaes podem car disponveis nos sistemas. O projeto Shibboleth [Shibboleth 2005] apresenta uma preocupao com a privacidade das informaes dos usurios, denindo como requisitos da arquitetura meios para gerenciar quais informaes um stio origem ir transferir para um stio destino, com o consentimento do usurio. Por m, um dos pilares mais importantes para a construo de aplicaes distribudas e de processos de negcios a conana entre as entidades participantes. O termo conana pode assumir diversos sentidos em uma aplicao distribuda. Em segurana, o mais usual como garantir que as informaes foram enviadas por uma origem convel. No caso, a preocupao geralmente restringe-se a garantir as propriedades de autenticidade e integridade das mensagens. Para tratar tal problema diversos modelos foram propostos, como por exemplo, o X.509 [Housley et al. 2002], o PGP [Zimmerman 1994] e o SPKI/SDSI [Ellison et al. 1999, Rivest e Lampson 1996]. Porm, a conana no se restringe simplesmente em garantir as propriedades de autenticidade e integridade. Em uma aplicao distribuda, as informaes trocadas entre clientes e provedores de servios possuem um certo valor e a manipulao indevida das mesmas pode acarretar em prejuzos para ambos os lados. Por exemplo, um cliente no gostaria de fornecer o nmero do carto de crdito para qualquer provedor de servio. A conana entre clientes e provedores de servio algo que pode ser estabelecido com base, por exemplo, em uma base de reputaes, o que poderia indicar que um determinado provedor de servios sempre honrou suas comunicaes. Em alguns trabalhos, assume-se que o estabelecimento de conana um processo

manual que exige o cumprimento de diversos requisitos burocrticos antes da criao da relao de conana. Por exemplo, para entrar na hierarquia das autoridades certicadoras do X.509 necessrio cumprir um conjunto de requisitos, sendo alguns destes relacionados a segurana fsica do local onde estar armazenada a chave privada da Autoridade Certicadora (AC). Outros trabalhos tratam a conana de uma maneira mais dinmica e voltil. Por exemplo, para um determinado uxo de negcios necessrio que diversos provedores de servio se agrupem e, uma vez que o uxo tenha sido cumprido, tal relao desfeita. 1.4.3. Especicaes de Segurana para Servios Web Com o objetivo de tornar seguro o uso dos Servios Web e assim garantir a sua ampla adoo, muitas propostas de segurana esto sendo submetidas a rgos como: World Wide Web Consortium (W3C)6 , Organization for the Advancement of Structured Information Standards (OASIS)7 e Web Services Interoperability Organization (WS-I)8 . As propostas visam cobrir diversas reas de segurana e, em conjunto com as especicaes de segurana para o padro XML, estas permitem garantir alguns dos requisitos de segurana apontados na seo anterior. XML Signature O uso de assinaturas de digitais uma forma para garantir as propriedades de integridade e autenticidade de informaes digitais. A especicao XML Signature (XMLDSign) [Bartel et al. 2002], proposta conjunta entre W3C e IETF, dene regras para gerar e validar assinaturas digitais expressas em XML. A XMLDSign possui pontos em comum com o Public Key Cryptography Standard #7 (PKCS#7), porm apresenta formas para tratar os novos desaos em se trabalhar com documentos XML. O desao em criar assinaturas expressas em XML est justamente na forma de codicao dos documentos XML. Por exemplo, para interpretadores XML, o elemento <Nome > e o elemento <Nome> so tratados da mesma forma. Porm, quando aplicado um algoritmo para assinatura digital, duas assinaturas distintas seriam geradas. A XML Canonical [Boyer 2001] dene meios para representar documentos XML na forma cannica. Documentos XML, que sejam sintaticamente diferentes, porm logicamente equivalentes, sero representados por uma mesma forma cannica. Assim, o uso da forma cannica possibilita que os documentos XML possam ser assinados sem que haja preocupao com a sintaxe dos mesmos. O uso da XMLDSign no est unicamente voltado para assinar documentos XML. possvel assinar qualquer tipo de documento eletrnico (arquivos binrios ou textos), sendo que a assinatura ser representada atravs de um documento XML. Tambm possvel assinar somente algumas partes de um documento XML, permitindo assim que outras partes de um documento XML sofram modicaes, sem que isso invalide a parte assinada. A XMLDSign no dene novos algoritmos criptogrcos, mas faz uso dos
6 http://www.w3.org 7 http://www.oasis-open.org 8 http://www.ws-i.org

algoritmos existentes, como o RSA [RSA 2002] e SHA-1 [Eastlake e Jones 2001]. As assinaturas podem ser representadas em trs diferentes formas (veja Figura 1.6): enveloped: a assinatura ca contida dentro do prprio documento XML a qual esta referencia. ideal para ser utilizada com Servios Web, inserida em mensagens SOAP; enveloping: os dados assinados, em XML ou no cam contidos dentro da prpria estrutura do XMLDSig; detached signature: a assinatura ca separada dos dados assinados. Isto ideal para assinar documentos que no esto disponveis localmente ou que sofrem constantes modicaes.
Documento XML assinado Assinatura

Documento assinado

Documento assinado Assinatura Assinatura Enveloping Detached Signature

Enveloped

Figura 1.6. Formas de assinaturas XMLDSign

XML Encryption A XML Encryption (XMLEnc) [Imamura et al. 2002] visa prover segurana m-a-m para aplicaes que necessitem realizar troca de dados de forma segura. Diferentemente dos protocolos TLS/SSL [Dierks e Allen 1999, Freier et al. 1996], que s garantem a condencialidade dos dados durante a sesso estabelecida entre duas partes, a XMLEnc garante condencialidade persistente, garantindo assim a condencialidade dos dados mesmo depois do trmino da sesso. A XMLEnc prov solues para algumas necessidades no cobertas pelo TLS/SSL, como a possibilidade de cifrar somente partes de um dado e o estabelecimento de sesses seguras entre mais de duas partes. Os dados cifrados so representados de uma forma estruturada e permitem que em um mesmo documento estejam presentes informaes cifradas e no cifradas. Tal estrutura ainda possibilita o uso de diferentes chaves para cifrar partes de um documento, permitindo assim que um mesmo documento seja trocado entre diversas partes, sem que ocorra a revelao de informao para partes no autorizadas e garantam o acesso informao, por partes autorizadas. De forma anloga ao XMLDsig, o XMLEnc representa, de forma estruturada, dados cifrados e permite cifrar documentos XML ou no. A estrutura do XMLEnc, alm de expressar os dados cifrados, tambm expressa detalhes sobre o tipo do documento

cifrado (jpeg, xml, etc.): a chave simtrica que ser utilizada na sesso; informaes sobre o tipo da chave simtrica; e o mtodo de cifragem utilizado (ex: RSA para cifrar a chave secreta e AES [Daemen e Rijmen 2002] para cifrar os dados).

XACML A autorizao uma propriedade bsica de segurana que determina se um principal pode ou no executar alguma ao sobre algum recurso. Geralmente, cada sistema utiliza uma linguagem prpria para denio das polticas, tornando assim um fator limitante para a concepo de sistemas distribudos e abertos. Visando garantir a interoperabilidade entre os diversos sistemas, o rgo OASIS lanou a eXtensible Access Control Markup Language (XACML) [OASIS 2005a], um sistema de polticas de propsito geral, baseado em XML. A XACML descreve uma linguagem para polticas de controle de acesso e tambm um formato para mensagens de pedido e resposta. A linguagem para poltica de controle de acesso utilizada para denir quem possui direitos de acesso sobre o qu. O formato de pedido e resposta descreve como as consultas sobre o sistema de polticas devero ser realizadas (pedido) e como devero ser as respostas. O formato de pedido e resposta dene as trocas ente o Policy Decision Point (PDP) [Yavatkar et al. 2000], ponto este que efetua o processamento da poltica, e o Policy Enforcement Point (PEP) [Yavatkar et al. 2000], ponto este que concretiza as decises de poltica. A XACML foi desenvolvida para garantir a interoperabilidade entre diversas aplicaes. Assim, uma camada de abstrao entre o ambiente da aplicao e a linguagem ncleo do XACML feita atravs de um Contexto XACML. Um Contexto XACML denido atravs de um esquema XML, que descreve uma representao cannica das entradas e sadas do PDP [OASIS 2005a]. Um pedido composto: (1) por atributos associados ao sujeito que est originando a requisio; (2) pela identicao do recurso desejado; (3) pelas aes que sero executadas no recurso; e tambm (4) pelos atributos do ambiente. J na resposta so contidas decises como: permit para acesso garantido; deny para acesso negado; not applicable para a inexistncia de poltica ou de regras associadas ao recurso; ou ainda indeterminate para a ocorrncia de erros durante o processamento [Lorch et al. 2003]. A Figura 1.7 ilustra o uxo de dados entre um cliente tentando acessar um recurso, utilizando-se do XACML. No passo 1 o sujeito (cliente) lana um pedido ao PEP, que monta um pedido XACML e encaminha ao Tratador de contexto (passo 2). O tratador de contexto encaminha o pedido para o PDP para que o mesmo decida sobre a tentativa de acesso (passo 3). O PDP pode requisitar ao Tratador de contexto atributos relacionados ao recurso e ao sujeito (passos 4, 5 e 6). De posse dos atributos, o PDP requisita as polticas associadas com as entidades envolvidas (passo 7) e assim gera uma resposta sobre a deciso tomada (passo 8). O Tratador de contexto gera uma resposta XACML e envia ao PEP (passo 9). E por m, o PEP garante ou no o acesso ao recurso (passo 10).

Requisitor
1. tentativa de acesso (opcionalmente com atributos)

Atributos
5. obtm atributos 2. pedido XACML 4. requisio de atributos

PEP
9. resposta XACML

Tratador de contexto

3. pedido sobre deciso

PDP
7. obtm polticas

8. resposta sobre deciso 6. atributos

Polticas

10. garante/nega acesso

Recurso

Figura 1.7. Fluxo de dados com o XACML [OASIS 2005a]

SAML A Security Assertion Markup Language (SAML) [OASIS 2005c] consiste de um conjunto de especicaes e esquemas XML, que juntos denem uma forma padro para criar, trocar e interpretar asseres de segurana entre entidades de uma aplicao distribuda. No caso, so denidos meios para expressar, em XML, informaes sobre autenticao, autorizao e atributos de um sujeitos, porm as especicaes da SAML no denem uma nova tecnologia ou forma para autenticao, mas sim uma tecnologia que visa garantir a interoperabilidade entre os diferentes sistemas de autenticao9 . Uma assero de segurana um conjunto de armaes, concedidas por um emissor SAML, sobre determinadas informaes de um principal. Na especicaes so denidas trs tipos de asseres: de autenticao, fornecida pelo emissor SAML aps o ato de autenticao com sucesso do usurio, que contm informaes relacionadas ao emissor, o principal autenticado, o perodo de validade, etc.; de atributo, que contm detalhes especcos sobre o principal em questo, por exemplo, um papel que o principal desempenha dentro do sistema; e de autorizao, que indica os direitos que um principal possui sobre um determinado recurso, sendo que esta assero pode levar como base as asseres de autenticao e de atributos. Apesar do modelo de uso do SAML prever o uso de autoridades responsveis pela emisso dessas asseres, as especicaes no fazem qualquer meno sobre as mesmas. Todavia, as especicaes denem os protocolos para que se possa interagir com essas autoridades. Em sua primeira verso, o principal objetivo do SAML era permitir a transferncia de autenticao e autorizao entre aplicaes Web (conana portvel). J a verso
especicao da SAML prev o uso de diferentes mecanismos para a autenticao: usurio e senha, Kerberos [Kohl e Neuman 1993], Secure Remote Password [Wu 1998], certicados TLS/SSL, chave pblica (X.509 [Housley et al. 2002], SPKI [Ellison et al. 1999], XKMS [Hallam-Baker e Mysore 2005]), XMLDSign e ainda, possibilita o uso de mecanismos no denidos na especicao.
9A

1.1 foi lanada com o intuito de melhorar a interoperabilidade e garantir uma melhor integrao com o XMLDSign. Por m, com base nas iniciativas do projetos Liberty Alliance (ver seo 1.5.1) e Internet2 Shibboleth [Carmody 2001], a verso 2.0 da SAML, recentemente lanada, tem como foco principal o uso de identidades federadas e ainda apresentando as seguintes caractersticas [OASIS 2005b]: pseudnimos: pseudnimos, ou identicadores opacos, permitem que principais interajam com o sistema sem a necessidade de revelar qualquer informao que o identique, como e-mail, nome, etc. O uso de pseudnimos impede que provedores entrem em comum acordo para cruzar informaes de um determinado principal e assim ferir sua privacidade; gerenciamento de identicadores: dene como dois provedores podero estabelecer e, em conseqncia, gerenciar os pseudnimos dos principais, com quem operam; metadados: estes denem como expressar dados de congurao e dados de conana, para tornar mais simples o uso do padro SAML, visto que as entidades participantes devem aceitar os mesmos papis, identicadores, pers, URL e certicados; cifragem: possibilita que atributos, identicadores ou toda a assero seja cifrada. Tal caracterstica permite garantir a condencialidade m-a-m; pers de atributo: estes simplicam a congurao e a implantao de sistemas que trocam dados de atributos. Denem como os atributos podero ser transportados nas asseres SAML. Denem um perl bsico, que utiliza os tipos primitivos do XML para expressar os atributos e tambm dene pers como X.500/LDAP, UUID10 e XACML; manuteno da sesso: o SAML 2.0 prov um protocolo que permite que todas as sesses, providas por uma autoridade de sesso, possam ser facilmente encerradas simultaneamente; suporte a dispositivos mveis: trata com as restries de processamento dos dispositivos e com a largura de banda; mecanismos de privacidade:permitem expressar as conguraes e polticas de privacidade dos provedores e principais, com relao ao uso da informao; descoberta do provedor de identidade: permite uma forma para localizar provedores de identidades, em ambientes em que existam mais de um provedor de identidade;
nico universal, denido pela Open Software Foundation (OSF) como parte do Distributed Computing Environment (DCE), uma vez criado por algum, tem-se a garantia que o mesmo no ser reutilizado por mais ningum [OpenGroup 1997].
10 Identicador

Nas verses 1.0 e 1.1 da SAML, o principal objetivo era transpor domnios atravs do uso da autenticao nica (Single Sign-On SSO), possibilitando que usurios autenticados em um domnio de segurana pudessem usufruir dessa autenticao em servios presentes em outros domnios, sendo isto transparente para o usurio. Para isto, o conceito de identidade federada utilizado. Neste caso, as entidades Provedor de Identidades e Provedor de Servios entram em um acordo sobre os atributos dos usurios, como por exemplo, o nome do usurio e atributos de sesso, cabendo ao Provedor de Identidades garantir a autenticidade dos mesmos ao Provedor de Servios. A Figura 1.8(a) ilustra um caso de identidade federada.
Provedor de Identidade Provedor de Servio
Provedor de Identidade Provedor de Servio A Provedor de Servio B

1. Autenticao

2. Joo e tem os direitos

ja456

jb123

3. Acesso ao servio

1. Autenticao

Joo

Joo

(a) Atributos federados

(b) Ligao entre contas

Figura 1.8. Identidade federada

Com a SAML 2.0, surgiu uma nova forma de uso de identidade federada, que permite a ligao entre contas. Neste caso, as diferentes identidades de um usurio, presentes em diferentes Provedores de Servio, podem ser associadas de forma que possibilite o SSO, porm sem ferir a privacidade do usurio. A SAML 2.0 prope o uso de pseudnimos, o que evita que Provedores de Servios entrem em acordo, visando rastrear as informaes de um determinado usurio. No caso apresentado na Figura 1.8(b), o Provedor de Identidade estabeleceu diferentes pseudnimos com os Provedores de Servios A e B, para referenciar um mesmo usurio, no caso Joo. Assim, Joo ao apresentar a assero ao Provedor A, reconhecido como o usurio local ja456; e ao apresentar a assero ao Provedor B, reconhecido como o usurio local jb123. Dessa forma, os provedores A e B no tero meios para rastrear o usurio Joo. XKMS Desenvolvida inicialmente pela VeriSign, em conjunto com a Microsoft e WebMethods, o padro XML Key Management Specication (XKMS) [Hallam-Baker e Mysore 2005] uma especicao aberta que dene interfaces, baseadas em Servios Web, visando retirar dos desenvolvedores de aplicaes a complexidade em se trabalhar com Infra-estrutura de Chave Pblica (ICP), podendo esta ser X.509, SPKI ou mesmo PGP [Zimmerman 1994]. A especicao dividida em duas sub-especicaes, XML Key Information Service

Specication (XKISS) e XML Key Registration Service Specication (XKRSS), que juntas denem meios para gerar pares de chaves, armazenar e localizar informaes sobre chaves pblicas, bem como para validar assinaturas. A especicao XKISS dene os servios que visam retirar das aplicaes a complexidade em se trabalhar com assinaturas expressas em XMLDSign [Bartel et al. 2002]. Informaes como nome da chave, ou um certicado X.509, ou a prpria chave, so descritas dentro do elemento XML <ds:KeyInfo> de uma assinatura em XMLDSign. Porm, a informao fornecida juntamente com a assinatura pode ser insuciente para que o receptor possa validar a mesma, ou ainda, a informao pode estar em um formato no qual o receptor no capaz de compreender. Por exemplo, dentro do elemento <ds:KeyInfo> s fornecido um nome para a chave utilizada, mas no a prpria chave em si. O XKISS dene dois servios: um para permitir a localizao de informaes relacionadas s chaves (XKISS Locate) e outro para vericar se estas informaes relacionadas s chaves so vlidas (XKISS Validate). O objetivo do servio XKISS Locate de somente localizar informaes relacionadas ao elemento <ds:KeyInfo>. Tais informaes podem ser obtidas em uma base local de dados ou atravs do encaminhamento de um pedido a outros servidores. Por exemplo, dentro de um elemento <ds:KeyInfo> poderia estar contido somente o email do criador da assinatura. Com essa informao, o XKISS Locate poderia localizar qual chave est associada com o e-mail e assim permitir que a assinatura seja validada. Porm as informaes retornadas pelo XKISS Locate no so validadas, sendo tal tarefa atribuda ao servio XKISS Validate. O XKISS Validate possibilita realizar as mesmas funes do XKISS Locate, porm o cliente pode obter uma assero garantindo a validao das informaes por este retornadas.
empresa.com.br

DNS
localize servio Locate (2) (1) localize chave valida

Locate

localize chave (3)

Validate

Figura 1.9. Uso combinado dos servios Locate e Validate [Hallam-Baker e Mysore 2005]

A Figura 1.9 ilustra um exemplo, em que os servios XKISS Locate e Validate so combinados com o intuito de localizar e validar uma assinatura. Neste exemplo, o usurio Joo aciona o seu servio XKISS Validate para encontrar, de forma convel, a chave pblica do usurio maria@empresa.com.br (passo 1). No caso, o XKISS Validate utiliza o servio de nomes (DNS) para localizar o servio XKISS Locate responsvel pelo domnio empresa.com.br11 (passo 2). Por m, o servio XKISS Validate aciona o
especicao 2.0 do XKMS [Hallam-Baker e Mysore 2005] dene meios para incluir informaes do XKISS nos registros do DNS.
11 A

servio XKISS Locate do domnio empresa.com.br para obter a chave pblica do usurio Maria (passo 3). Como visto, o objetivo dos servios propostos na especicao XKISS de localizar e validar as informaes associadas com as chaves pblicas, sendo que o registro e o gerenciamento destas informaes esto dentro do contexto das facilidades providas pela especicao XKRSS. Tal especicao dene servios para: (1) o registro de informaes; (2) a reemisso das informaes associadas a chaves, permitindo gerar novas credenciais na ICP subjacente, por exemplo, no caso de um certicado expirar; (3) a revogao das informaes associadas; e, (4) para a recuperao de uma chave privada, associada anteriormente. Neste ltimo caso, s possvel recuperar a chave privada, somente se o par de chaves em questo foi gerado anteriormente pelo prprio XKRSS. Cada protocolo denido pela XKMS prov suporte a diversas opes, incluindo opes de processamento das mensagens trocadas. Cabe ao cliente especicar quais opes este est apto a tratar e assim o servio XKMS poder decidir se aceita ou no o pedido, sendo que tal deciso depender de sua prpria poltica de negcio. As opes para o processamento das mensagens podem ser: sncrona o servio responde ao pedido assim que o processamento for nalizado; assncrona o servio pode no conseguir responder ao pedido imediatamente, mas notica o cliente que o pedido ainda no foi satisfeito, posteriormente, o cliente poder novamente invocar o servio com o objetivo de obter a resposta nal; pedidos de duas fases diferente do assncrono, nesta opo no h atraso entre o pedido inicial e o envio da resposta nal. Tal forma de processamento , basicamente, utilizada como um tipo de proteo contra ataques de negao de servio. A Figura 1.10 ilustra as opes de processamento previstas para o XKMS. No caso do processamento sncrono, o servio, ao receber o pedido P, executa a operao requisitada e j envia uma resposta, composta pelo resultado e por um cdigo (Final), o qual indica que a transao foi encerrada com sucesso.
sncrona
XKMS

assncrona

duas fases

P Pendente id

P+id

P+nonce

Cliente

Final

Final

nonce

Final

Figura 1.10. Tipos de processamento os pedidos XKMS

No processamento assncrono, o cliente envia um pedido inicial P ao servio para registrar uma chave, por exemplo. Segundo a poltica do servio em questo, um pedido de registro de chaves requer a interao com o administrador do servio, assim o pedido ca pendente at que o administrador aprove ou no o registro. Neste caso, o servio responde o pedido inicial, feito pelo cliente, indicando que o processamento est pendente e fornece tambm um identicador para esta pendncia (id). O cliente com este identicador em mos pode, em um prximo pedido, vericar se o pedido inicial P j foi

processado e em caso armativo o servio responde ao pedido P juntamente com o cdigo Final para indicar o trmino da transao. A poltica de segurana do servio XKMS pode determinar que o servio s aceitar requisies de clientes autenticados, estes j presentes na lista de controle de acesso do servio, por exemplo. Dessa forma, todos os pedidos que chegam ao servio devem ser assinados e cabe ao servio vericar tais assinaturas. Sabe-se que as vericaes de assinaturas digitais possuem um certo custo de processamento e intrusos poderiam inundar o servio XKMS com requisies falsas, com o objetivo de provocar uma negao de servio. O processamento de duas fases visa coibir tal tipo de ataque. Para isso, o servio ao receber um pedido inicial P de um cliente (ver Figura 1.10) responde para este enviando um nonce12 e indicando que o cliente dever executar um novo pedido, juntamente com este nonce. O objetivo do nonce garantir uma autenticao fraca, ou seja, o servio s ir realmente vericar a assinatura de pedidos que estejam acompanhados de nonces, emitidos por ele. Assim, evita-se processar assinaturas de pedidos falsos. Pedidos, que forem novamente encaminhados com o nonce, sero processados e sero respondidos juntamente com o cdigo Final para indicar o trmino da transao. WS-Security Proposta apresentada inicialmente pela IBM e Microsoft, a WS-Security [OASIS 2004c] hoje uma especicao padronizada pela OASIS que tem como objetivo a proposio de extenses ao SOAP para permitir a construo de Servios Web seguros. A especicao visa garantir a segurana m-a-m no nvel de mensagem e no somente no nvel de transporte, tendo trs principais pontos: credenciais de segurana: incluir nas mensagens SOAP credenciais de segurana com informaes de autenticao; integridade da mensagem: incluir nas mensagens SOAP informaes relacionadas a assinaturas digitais de toda ou de parte da mensagem; condencialidade da mensagem: mensagens SOAP podem ser cifradas, totalmente ou somente partes dela. A WS-Security dene um esquema XML, o qual possibilita incluir de forma padronizada as informaes relacionadas a assinatura e a cifragem dos dados da mensagem SOAP em questo, fazendo uso das especicaes XMLDSign [Bartel et al. 2002] e o XMLEnc [Imamura et al. 2002]. Tais informaes so inseridas dentro de elementos XML <wsse:Security> e cada mensagem SOAP poder conter um ou mais destes elementos. Isso se justica devido ao fato que o caminho percorrido por uma mensagem SOAP, da origem at o destino nal, pode ser composto por diversos ns SOAP intermedirios. Neste caso, a WS-Security consegue garantir que somente determinadas partes de uma mensagem SOAP possam ser lidas, modicadas por determinados ns intermedirios.
12 Nmero

pseudo-aleatrio utilizado uma nica vez (do ingls: number used once).

Dessa forma, a WS-Security permite a incluso de mltiplas assinaturas e cifragens nas mensagens SOAP. Cada elemento <wsse:Security> dever identicar, atravs do atributo SOAP1.2:role, o n a qual aquela informao est direcionada. No permitido que haja dois elementos <wsse:Security> que tenham como alvo um mesmo n SOAP, porm informaes como a assinatura do emissor inicial podem ser interessantes para todos os ns SOAP intermedirios ou nal. Desta forma, possvel denir um nico elemento <wsse:Security> sem que necessite indicar o n relacionado com este elemento. Isso permite que todos os ns SOAP possam tratar tal elemento. Cada n intermedirio s pode processar o elemento <wsse:Security> direcionado a ele, podendo assim remov-lo ou mesmo adicionar novos elementos <wsse:Security>, antes de encaminhar para o prximo n, presente no caminho da mensagem SOAP. possvel tambm que cada n intermedirio adicione novos subelementos a um elemento <wsse:Security> j existente.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<soapenv:Envelope xmlns:soapenv="..." xmlns:wsse="..."> <soapenv:Header> <wsse:Security> <wsse:UsernameToken wsu:Id="..."> <wsse:Username>joao</wsse:Username> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> <soapenv:Body> ... </soapenv:Body> </soapenv:Envelope> Figura 1.11. Mensagem SOAP ilustrando o WS-Security

A Figura 1.11 apresenta um exemplo de uma mensagem SOAP com o cabealho da WS-Security. O exemplo consiste em enviar uma simples credencial, no caso joo (linha 7), sem qualquer tipo de proteo. Na linha 2 da gura, so informadas as URI13 para os espaos de nomes XML do SOAP e da WS-Security. Cada elemento <wsse:Security> (linhas 5 a 9) pode expressar informaes sobre a cifragem, a assinatura e sobre as credenciais de segurana. As linhas 6 a 8 expressam detalhes sobre uma credencial de segurana, porm os elementos <wsse:Security> podem conter mais de uma credencial de segurana, se desejado for. Em um cenrio de uso para a mensagem apresentada na Figura 1.11, um n SOAP, aps receber uma invocao de um cliente, autenticado atravs de um mecanismo presente nas camadas subjacentes (como TLS/SSL), encaminha tal mensagem para outro n SOAP, sendo que ambos os ns estariam presentes dentro de um mesmo ambiente considerado convel e seguro. Assim, o objetivo da mensagem indicar ao n SOAP nal que, em um n SOAP mais externo, a autenticao do cliente j foi realizada e esta informao est
13 A

URI foi suprimida para facilitar a visualizao do cdigo.

sendo repassada atravs do elemento <wsse:Username> (linha 7). Supe-se tambm que a segurana da comunicao entre os ns SOAP garantida atravs, por exemplo, do TLS/SSL. A Figura 1.12 ilustra tal cenrio.
<wsse:Username> joo </wsse:Username> canal TLS/SSL

Cliente

pedido + assinatura canal TLS/SSL

Servio Web

Servio Web Domnio

Figura 1.12. Encaminhando a identicao do cliente [Weerawarana et al. 2005]

No exemplo apresentado na Figura 1.12, a condencialidade e a integridade das mensagens so garantidas atravs do uso do TLS/SSL, ou seja, no nvel de transporte. Porm, pode-se ainda usar os padres XMLEnc e do XMLDSign para garantir tais propriedades, evitando assim a necessidade do TLS/SSL. Outra forma ainda a combinao do TLS/SSL com o XMLEnc e o XMLDSign. Atualmente, a especicao WS-Security prov suporte a dois tipos de credenciais de segurana: credenciais UsernameToken e credenciais BinarySecurityToken. Um uso para a credencial UsernameToken foi descrito anteriormente e apresentado na Figura 1.12. J a credencial BinarySecurityToken apresenta uma forma padro para anexar a um pedido SOAP qualquer credencial de segurana codicada em forma binria; por exemplo, certicados X.509, tickets Kerberos, etc. Polticas para os Servios Web Como visto anteriormente, a especicao WSDL surgiu da necessidade de um padro para especicar as funcionalidades presentes em um Servio Web. A WSDL permite aos provedores de servios especicar quais so os servios oferecidos, quais informaes so necessrias para invocar um servio e como dever ser o formato para troca de informaes com os clientes. A WSDL s se preocupa em descrever as propriedades funcionais de um servio, porm, necessrio uma forma padronizada e interopervel, para descrever as habilidades e requisitos no funcionais de um servio. Tais habilidades no funcionais podem estar relacionadas com a segurana provida ou exigida pelo servio. Os clientes, com base nessas informaes, podem determinar qual servio escolher, visando, por exemplo, servios que apresentem uma poltica de privacidade bem denida, ou ainda, que garantam condencialidade nas transaes. Como representar e anexar tais informaes aos servios ou recursos dentro do ambiente dos Servios Web, serviu de motivao para o surgimento de documentos como o WS-Policy [WS-Policy 2004] e o WS-PolicyAttachment [WS-PolicyAttachment 2004]. A especicao WS-Policy prov um modelo de propsito geral para descrever polticas. Prov uma gramtica exvel e extensvel que permite descrever uma ampla variedade de requisitos e habilidades para o ambiente dos Servios Web. A especicao WS-PolicyAttachment descreve como associar polticas com os determinados recursos e

tambm dene como associar polticas a elementos XML que compem um documento WSDL e a elementos UDDI. Juntamente com o WSDL, o WS-Policy prov uma descrio declarativa dos requisitos que o servio possui, os quais devero ser cumpridos pelos requisitante. Porm, o uso de polticas no se limita somente aos servios. Dentro do ambiente dos Servios Web, existe uma ampla variedade de recursos, como documentos XML, sesses de mensagens conveis nas quais se podem associar polticas. A especicao WS-Policy apresenta uma estrutura para descrio de polticas dividida em trs principais componentes: assero de poltica expressa a habilidade do recurso, especca a um domnio, por exemplo, permitir a troca convel de mensagens; alternativas de polticas descrevem as combinaes aceitveis de obrigaes e requisitos (conjunto de asseres de poltica), para a interao entre o servio e um requisitor ou ainda para o acesso a um recurso; poltica expressa um conjunto de alternativas de polticas vlidas. Segundo a WS-Policy, as polticas so representadas atravs de documentos XML, cujo elemento raiz do documento o elemento Policy. Dentro deste elemento so representadas colees de asseres, que quando combinadas representam um conjunto vlido de alternativas de polticas . As asseres so combinadas atravs de dois tipos de operadores de polticas: ExactlyOne indica que somente uma das asseres contidas na poltica poder fazer parte de uma alternativa de poltica; All permite a combinao de todas as asseres apresentadas como uma alternativa de poltica.
1 2 3 4 5

<wsp:Policy ...> <wsp:ExactlyOne> [ <wsp:All> [ <Assertion> ... </Assertion> ]* </wsp:All> ]* </wsp:ExactlyOne> </wsp:Policy> Figura 1.13. Forma normal para expressar polticas [WS-Policy 2004]

Os operadores ExactlyOne e All podem ser combinados de diversas formas. Visando facilitar a interoperabilidade das polticas expressas pela WS-Policy, a especicao deniu uma forma normal para expressar as polticas. A Figura 1.13 apresenta a estrutura que uma poltica deve seguir para se adequar forma normal. Dessa forma, cada alternativa de poltica vlida ca contida dentro de um elemento All (linha 3) e todas as alternativas de polticas devero estar contidas dentro de um nico elemento ExactlyOne (linhas 2 a 4)14 . Isso indica que s possvel escolher uma nica alternativa e esta alternativa consiste na expresso completa de todas as asseres ali descritas [Weerawarana et al. 2005]. A especicao da WS-Policy tambm dene um algoritmo para a traduo de qualquer expresso de poltica para a forma normal. A Figura 1.14 ilustra uma poltica expressa de acordo com a forma normal da WS-Policy. No exemplo, a poltica indica que credenciais Kerberos ou X.509 podem ser utilizadas para prover a autenticao em um determinado recurso. As linhas 3 a 7 e 8 a
14 O

smbolo *, de acordo com a notao do XML, indica a presena de 0 ou mais elementos.

12 apresentam duas alternativas de poltica e somente uma das duas alternativas poder ser selecionada. Se a primeira for selecionada, indica que somente credenciais Kerberos sero aceitas e no caso de ser selecionada a segunda, ento somente credenciais X.509 sero aceitas.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<wsp:Policy> <wsp:ExactlyOne> <wsp:All> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType> </wsse:SecurityToken> </wsp:All> <wsp:All> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3</wsse:TokenType> </wsse:SecurityToken> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> Figura 1.14. Uma poltica expressa de acordo com a WS-Policy [WS-Policy 2004]

Geralmente, o provedor de um Servio Web expe sua poltica com o objetivo de indicar sob quais condies ir prover seu servio, ou seja, informa suas habilidades e seus requisitos. Um possvel cliente, aps analisar a poltica, pode decidir se est apto ou se deseja acessar o servio ou no. A especicao da WS-Policy dene somente uma gramtica para expressar polticas, porm no especica como associar tais polticas aos Servios Web ou mesmo como divulg-las, permitindo que outras especicaes determinem como associar polticas de acordo com uma tecnologia especca. Essa separao da denio das polticas com a associao aos recursos permite que as polticas possam ser reutilizadas. A WS-PolicyAttachment [WS-PolicyAttachment 2004] dene diversos mecanismos para associar as polticas aos recursos. Dentro do ambiente dos Servios Web, os recursos podero ser uma troca de mensagens, um servio, uma coleo de servios, etc. A WS-PolicyAttachment dene mecanismos que permitem que as polticas sejam anexadas diretamente dentro de documentos XML ou ainda permitem associar as polticas com os recursos de forma que no necessitem que as polticas e os recursos estejam presentes dentro de um mesmo documento XML. Diversos tipos, presentes nos documentos WSDL, podem constituir um recurso, como os elementos messages, portType, binding, service, entre outros. As polticas podem ser anexadas aos documentos WSDL, atravs de elementos PolicyReference. Tambm vale citar a proposta WS-SecurityPolicy [WS-SecurityPolicy 2005] que tem por objetivo descrever como dever ser a segurana no nvel de mensagens, utilizando para isso as especicaes WS-Security [OASIS 2004c], WS-Trust [WS-Trust 2005] e WS-SecureConversation [WS-SecureConversation 2005].

WS-Trust Desenvolvida por um conjunto de empresas, lideradas pela Microsoft e IBM, a especicao WS-Trust [WS-Trust 2005] dene servios e protocolos visando a troca de atributos de segurana (p.ex.: asseres SAML), para possibilitar a comunicao entre diferentes domnios administrativos e de segurana. A especicao WS-Trust apesar de ser bastante citada em trabalhos acadmicos e aparecer em algumas ferramentas de desenvolvimento para Servios Web, ainda no recebeu aval de entidades padronizadoras. Porm, recentemente o rgo OASIS criou um comit tcnico, OASIS WS-SX TC15 , que objetiva denir padres para a troca convel de mensagens SOAP e o trabalho envolvido consistir em renamentos das propostas WS-Trust, WS-SecurityPolicy [WS-SecurityPolicy 2005] e WS-SecureConversation [WS-SecureConversation 2005], trazendo assim importncia para tais propostas, que brevemente podero se tornar padres de fato. O servio de atributos de segurana (Security Token Service STS) denido pela WS-Trust como a autoridade responsvel por emitir, renovar e validar os atributos de segurana, sendo este a base do modelo de conana. O STS consiste de um Servio Web que implementa uma interface WSDL, especicada pela WS-Trust, e que processa mensagens SOAP seguras, ou seja, que est de acordo com a especicao WS-Security [OASIS 2004c]. A interface do STS dene duas operaes, a RequestSecToken para realizar o pedido e a RequestSecTokenResp para a obteno dos atributos de segurana.
STS
Poltica

Cliente

Servio Web
Poltica

Figura 1.15. O uso do STS na mediao de conana

A Figura 1.15 ilustra um caso tpico de conana mediada atravs do STS. O cliente deseja invocar o Servio Web, porm de acordo com as polticas deste servio (ex: expressas de acordo com a WS-Policy), necessrio que o cliente apresente credenciais de segurana emitidas pelo STS. Assim, o cliente deve obter as credenciais junto ao STS para que depois possa novamente invocar o servio. possvel que o STS tambm exija algum tipo de autenticao do cliente. Uma vez que o STS tenha analisado as credenciais fornecidas pelo cliente e vericado que as mesmas cumprem os requisitos necessrios, o STS responde com a mensagem RequestSecTokenResp, que contm as credenciais necessrias para que o cliente consiga acessar o Servio Web. A autenticidade da resposta pode ser garantida atravs de assinaturas digitais e a resposta ainda pode conter informaes adicionais, como tempo
15 http://www.oasis-open.org/committees/ws-sx

de vida da credencial e mecanismos para proteo contra ataque de mensagens antigas. Por m, o cliente efetua um novo pedido ao Servio Web, juntamente com as credenciais de segurana obtidas junto ao STS. O Servio Web verica as credenciais apresentadas e assim garante o acesso ao recurso. A WS-Trust no se preocupa com as tecnologias de segurana subjacentes, deixando a escolha para o desenvolvedor da aplicao. O uso combinado das tecnologias de segurana presentes nas camadas de rede ou de transporte pode ser utilizado para garantir a autenticao do pedido em si. Por exemplo, o uso de assinatura de digital para provar que o cliente realmente o detentor dos atributos apresentados ao servio. A especicao da WS-Trust no se preocupa com o estabelecimento das relaes de conana, mas usufrui das relaes j estabelecidas, possibilitando assim que partes que no possuem relaes estabelecidas possam se comunicar. As relaes de conana podem ser obtidas: (1) atravs de razes xas, em que denido um conjunto xo de entidades em quem se cona; (2) atravs de conana hierrquica, em que a conana dada atravs de uma rvore e os ns inferiores conam nos ns superiores; ou ainda, (3) atravs do uso das redes de conana, em que cada entidade determina em quem conar. WS-Federation A WS-Federation uma proposta lanada pela Microsoft e IBM que apresenta meios para permitir que diferentes domnios de segurana possam criar federaes de identidades e usufruir da mediao de conana destas para permitir o compartilhamento de identidades, atributos e autenticao entre os participantes. Para isso, a WS-Federation faz uso dos modelos denidos nas especicaes WS-Security [OASIS 2004c], WS-Policy [WS-Policy 2004] e WS-Trust [WS-Trust 2005], sendo que o STS, denido pela WSTrust, assume tambm o papel de um provedor de identidades. Ainda so denidas duas sub-especicaes para a WS-Federation. A especicao WS-Federation Passive Requestor [WS-Federation 2003c] detalha como implementar as funcionalidades da federao em ambientes com clientes passivos. Os navegadores Web so considerados clientes passivos, pois no esto aptos a tratar as respostas SOAP enviadas por um Servio Web. Desta forma, o processamento das mensagens dever ter como base as funcionalidades do protocolo HTTP 1.1 (GET, POST, redirects e cookies). J a especicao WS-Federation Active Requestor [WS-Federation 2003b] dene como implementar as funcionalidades da federao em ambientes com clientes ativos. Clientes ativos so aqueles que esto aptos a emitir mensagens e reagir com as respostas de um Servio Web, fazendo uso dos mecanismos denidos nas especicaes WS-Security, WS-Trust e WS-Federation. Em geral, clientes ativos podem obter uma poltica, enviada atravs de uma mensagem de erro de um Servio Web, processar essa poltica, obter as credenciais de segurana necessrias e refazer um novo pedido ao Servio Web inicial.

1.5. Reviso da Literatura de Segurana em Servios Web

Nesta seo sero apresentados alguns trabalhos que juntos cobrem diversas necessidades de segurana para a concepo de aplicaes distribudas, como o exemplo do portal de informaes apresentado na seo 1.3.4. Os trabalhos esto focados em trs dife-

rentes reas, sendo alguns destinados aos problemas de gerenciamento de identidades, o que envolve questes de privacidade e anonimato; outros focados aos problemas de gerenciamento de polticas; e por m alguns trabalhos voltados para o gerenciamento de conana. 1.5.1. Gerenciamento de Identidades Uma identidade digital consiste na representao de uma entidade em um domnio especco e geralmente est relacionada a domnios do mundo real. Uma entidade pode possuir mltiplas identidades, em que cada identidade constituda por um conjunto de caractersticas, podendo estas serem nicas ou no a um domnio. A identidade pode ser temporria ou permanente e pode assumir diferentes conotaes, dependendo do contexto no qual esta se encontra. Para uma pessoa a identidade pode estar associada ao nome, endereo, documento de identidade. J no contexto de uma empresa, a identidade pode estar associada com funes, privilgios, direitos e responsabilidades [Parr e Villars 2001]. O gerenciamento de identidades consiste de um sistema integrado de polticas, processos de negcios e tecnologias que permite s organizaes controlar o acesso aos recursos providos aos seus usurios de forma segura, provendo condencialidade s informaes dos usurios. Diversos modelos foram propostos para o gerenciamento de identidades e em [Jsang e Pope 2005, Jsang et al. 2005] apresentada uma breve descrio de alguns modelos. O modelo tradicional de gerenciamento trata a identicao de forma isolada, sendo que o provedor de servio tambm atua como o provedor de identidades e de credenciais (senhas associadas com os identicadores). Neste modelo, os usurios possuem identicadores nicos e especcos para cada servio com o qual interagem, resultando assim em diferentes credenciais associadas com cada identicador. O modelo de gerenciamento de identidades federadas surgiu para suprir as necessidades apresentadas pelo modelo de gerenciamento tradicional. Neste tipo de ambiente, denido o conceito de domnios, nos quais esto presentes os provedores de servio, de identidades e de credenciais, por exemplo, relacionados a uma determinada empresa. Assim, cada empresa constitui um domnio. O projeto Liberty Alliance (ver seo 1.5.1) e o projeto Shibolleth [Carmody 2001] so implementaes abertas de modelos de gerenciamento de identidade federada. No ambiente de identidades federadas, so estabelecidos acordos entre os domnios, os quais permitem que identidades locais a um domnio sejam reconhecidas nos demais domnios participantes do acordo. Neste caso, estabelecido o mapeamento dos identicadores de um usurio em diferentes domnios. Por exemplo, o identicador joao.pedro@empresa, oriundo do domnio empresa, dentro do domnio universidade, ser mapeado para o identicador jp@universidade. A federao de domnios de identicao d a impresso aos usurios de possurem um identicador nico para todos os domnios que compem a federao. Os usurios podero continuar a manter identicadores locais a cada servio ou mesmo domnio, porm o simples fato de possurem tal identicador permite que estes usurios possam acessar servios presentes

em qualquer domnio da federao. No modelo centralizado de gerenciamento, considera-se a existncia de um nico provedor de identidades e de credenciais em uma federao, o qual utilizado por todos os provedores de servios da mesma. Neste modelo um usurio pode acessar todos os servios presentes na federao utilizando um mesmo identicador. Em tese, o modelo se assemelha ao modelo de identidade federada, porm com a diferena de no necessitar do mapeamento de credenciais. A WS-Federation [WS-Federation 2003a] um exemplo deste tipo de modelo. [Damiani et al. 2003] apresenta um estudo sobre os problemas inerentes ao gerenciamento de mltiplas identidades, descrevendo os requisitos necessrios que um sistema de gerenciamento de identidades deve atender. Dentre os requisitos apresentados, alguns esto diretamente preocupados com as necessidades de segurana dos clientes [W3C 2002, Rannenberg 2000, Asokan et al. 1997], como a privacidade, o anonimato, a responsabilidade, etc. A seguir, sero apresentados alguns trabalhos que buscam atender estes requisitos dentro da arquitetura dos Servios Web. Privacidade A especicao [W3C 2004a] apresenta algumas consideraes sobre a privacidade na arquitetura dos Servios Web, indicando que tal assunto ainda no est completamente solucionado e necessita de um estudo mais aprofundando. Em [W3C 2004b] so apresentados alguns requisitos para a arquitetura dos Servios Web, necessrios para garantir a proteo da privacidade dos clientes de um Servio Web, sendo estes: a arquitetura deve permitir expressar polticas de privacidade sobre os Servios Web; a poltica de privacidade de um Servio Web deve ser expressa de acordo com a Platform for Privacy Preferences (P3P) [W3C 2002]; a arquitetura deve prover um meio para que os clientes possam vericar as polticas de privacidade dos Servios Web; a arquitetura deve permitir a propagao e a delegao da poltica de privacidade; os Servios Web devem permitir interaes onde uma ou mais partes so annimas. A Platform for Privacy Preferences (P3P) [W3C 2002] um projeto do W3C que permite que os stios web expressem suas polticas de privacidade de forma padronizada utilizando XML, dando aos usurios o conhecimento sobre como seus dados pessoais sero tratados. A P3P prov ferramentas que permitem que o administrador de um stio web, atravs de uma lista de requisitos, preencha como ser a poltica de privacidade do stio. Uma vez indicados todos os requisitos, a ferramenta retorna um cdigo XML que pode ser facilmente associado a um stio web. Navegadores web, compatveis com a P3P, podem

obter a poltica dos stios, comparar com as preferncias de privacidade do usurio e decidir sobre a continuidade da transao com o stio. A P3P no dene um padro mnimo para garantir a privacidade e tambm no prov meios para monitorar se os stios web esto honrando suas polticas. A P3P s dene uma forma padro para que stios e clientes web possam informar e vericar as polticas de privacidade aplicadas naquele stio web. Segundo [Hung et al. 2004], o uso do P3P no pode ser diretamente aplicado no contexto dos Servios Web, visto que o P3P foi projetado para que usurios de stios web possam ter controle sobre suas informaes pessoais. Outro problema que os vocabulrios da P3P esto direcionados principalmente para descrever as prticas de privacidade dos stios web, sobre quais dados iro coletar dos usurios e o que iro fazer com essas informaes. Dessa forma, possvel concluir que os requisitos apresentados em [W3C 2004b] ainda no atendem a real necessidade existente no ambiente dos Servios Web, o que exige a criao de novas solues para a rea. Anonimato O anonimato uma propriedade que est diretamente relacionada com a privacidade, porm com signicado distinto. O acesso annimo de um usurio a um sistema indica que o usurio no ser identicado, garantindo assim a privacidade de sua identidade real. Segundo [Cattaneo et al. 2004], em cenrios onde os recursos podem ser acessados de forma annima, porm por usurios autorizados pelas polticas de acesso do sistema, as solues triviais poderiam seguir duas linhas: Restringir o acesso aos recursos com base no endereo de rede de um determinado domnio. Dessa forma, todos os usurios que estiverem dentro da rede, dita convel, tero completo acesso ao recurso e de forma annima. Porm, tal soluo possui como pontos fracos a possibilidade de um usurio no autorizado conseguir acesso aos recursos pelo simples fato de estar na rede convel, e negar o acesso a um usurio autorizado, pelo fato deste estar em uma rede no convel. Fazer uso de credenciais de grupo. Por exemplo, o provedor do servio poderia emitir certicados de grupo para todos os usurios autorizados, indicando que o usurio pertence ao grupo de usurios conveis. Porm, um usurio, dito convel, poderia ceder tal certicado a terceiros, comprometendo assim a segurana do sistema, sendo que em alguns casos ca impossvel determinar qual dos usurios conveis delegou o certicado de grupo. Em [Cattaneo et al. 2004] apresentada uma extenso ao SOAP [W3C 2003] para permitir o acesso annimo aos Servios Web. A soluo est baseada no fato de que os usurios s precisam provar, para um provedor de servios, que pertencem a um determinado grupo, autorizado pelas polticas do sistema, evitando assim revelar sua identidade pessoal. A proposta dos autores consiste de uma variao do modelo para identicao

annima de grupo introduzida em [Santis et al. 1998]. Este modelo apresenta um protocolo com prova de conhecimento zero (zero-knowledge proof ) [Goldwasser et al. 1989] que permite um usurio se identicar, de forma annima, para um sistema remoto.
Cliente
Gerador de provas

Provedor de Servios
Verificador de provas

Cliente
1 2 6

Servio Web
5

chaves

2
Tratador de cabealho

4 4
Tratador de cabealho

chaves

Interpretador SOAP

3 6

Interpretador SOAP

Figura 1.16. Pedido com identicao de grupo annima [Cattaneo et al. 2004]

Para adicionar o anonimato de forma transparente para os Servios Web, a proposta em [Cattaneo et al. 2004] dene os componentes gerador de provas, presente no lado do cliente, e o servio para vericao de provas, presente no lado do Servio Web (veja a gura 1.16). As mensagens SOAP, originadas pela aplicao cliente so interceptadas, implicitamente ou explicitamente, pelo gerador de provas o qual ir gerar uma credencial de identicao annima e incluir no cabealho SOAP, juntamente com um marcao temporal (passo 2). Da mesma forma, no lado do Servio Web o pedido interceptado e encaminhado ao servio para vericao de provas, o qual verica se a credencial vlida (passo 4). Projeto Liberty Alliance O projeto Liberty Alliance consiste em um conjunto de especicaes produzidas por um consrcio de empresas atuantes nas mais diferentes reas, como em telecomunicaes, transportes, universidades, bancos, empresas de software, etc. Tem como principal objetivo criar especicaes abertas para tratar o gerenciamento de identidades, usufruindo do conceito de federao de identidades. Os principais objetivos do projeto so [Liberty 2003a]: permitir aos usurios garantir a privacidade e a segurana de suas informaes pessoais; prover um padro aberto para permitir uma nica autenticao (SSO), o que inclui a autenticao descentralizada e a autorizao em mltiplos provedores de servios; prover especicaes, compatveis com uma grande variedade de dispositivos; utilizar, em suas especicaes, sistemas, padres e protocolos existentes e amplamente aceitos;

 prover meios para que as empresas respeitem os requisitos de segurana e a privacidade dos clientes. Esses objetivos podem ser alcanados quando provedores de servios e clientes agrupam-se baseados em acordos comerciais e nas tecnologias propostas pela Liberty, formando assim os crculos de conana. Tais crculos consistem na federao de provedores de servios e servios de identidade, juntamente com os clientes. A Figura 1.17 ilustra a arquitetura da Liberty Alliance dividida em quatro mdulos.
Especificaes de Interfaces para Servios de Identidades (IDSIS)

Arcabouo para Federao de Identidade (IDFF) 1

SAML HTTP XML WSS TLS WAP

Arcabouo de Indentidade para Servios Web (IDWSF) 3

WSDSL SOAP XMLEnc XMLDSign

Figura 1.17. Arquitetura da Liberty Alliance [Liberty 2003a]

O mdulo 1, Liberty Identity Federation Framekwork (IDFF), da gura 1.17 visa permitir a federao de identidades e o gerenciamento das mesmas atravs de caractersticas como ligao entre diferentes contas ou identidades, autenticao nica (SSO) e o gerenciamento de sesses de forma simplicada. O mdulo 2 ilustra a preocupao da Liberty em adotar e estender, de forma apropriada, os padres da indstria ao invs de inventar novas especicaes que atuariam de maneira semelhante s j existentes. Algumas das extenses da Liberty propostas para o SAML, por exemplo, foram aceitas pelo rgo OASIS e esto presentes na verso 2.0 da especicao do SAML [OASIS 2005c]. No mdulo 3, Liberty Identity Web Services Framework (IDWSF), denida uma estrutura para criao, descoberta e acesso aos servios de identidade. A possibilidade de que empresas ofeream servios personalizados para os clientes, de acordo com os atributos e preferncias que estes clientes escolheram compartilhar, uma das principais caractersticas deste mdulo. No mdulo 4, Liberty Identity Services Interface Specications (IDSIS) , denida uma coleo de especicaes para a construo de servios interoperveis sobre a ID-WSF. Tais especicaes foram denidas para permitir que organizaes possam facilmente criar ou estender servios sobre a estrutura da ID-WSF. Uma das especicaes propostas foi a ID-Personal Prole, que dene um servio para obter informaes pessoais de um usurio como nome, endereo, telefone, etc. Tal especicao permite que todas organizaes que estejam de acordo com a Liberty possuam um conjunto de campos e valores conhecidos, tendo assim um dicionrio e uma linguagem padro para que possam interagir entre si. J esto sendo denidas especicaes para obter informaes de um usurio relacionadas ao seu emprego, sobre sua geo-localizao, etc.

Algumas especicaes do projeto Liberty Alliance esto direcionadas para garantir a segurana e a privacidade dos clientes. Em [Liberty 2003b], um guia de boas prticas para serem seguidas pelos provedores de servios que estejam de acordo Liberty apresentado, frisando que cada empresa ainda dever estar de acordo com a jurisdio a qual est submetida. No guia descrito que os servios devero informar, de forma clara, aos usurios quem est coletando suas informaes pessoais, quais informaes esto sendo coletadas e de que forma esto sendo coletadas. Os servios devero acatar as escolhas do usurio, com relao a privacidade de suas informaes pessoais. O usurio deve ter o direito de escolher quais atributos um provedor de servio ter acesso, bem como os meios para permitir gerenciar e indicar o tempo de vida das informaes fornecidas. Deve-se tambm prover mecanismos para resoluo de conitos para o caso de um usurio acreditar que suas informaes no estejam sendo manuseadas de forma incorreta. O guia tambm apresenta a necessidade de mecanismos que garantam o acesso s informaes pessoais de outros usurios, principalmente quando amparado por uma ao judicial. Os identicadores opacos ou pseudnimos foram propostos nas especicaes da Liberty com o intuito de garantir a privacidade dos usurios dos servios. Para cada provedor de servio, o provedor de identidade poder atribuir diferentes pseudnimos relacionados a um mesmo usurio. Dessa forma, o mesmo usurio seria representado por diferentes pseudnimos para cada servio que fosse acessar, garantindo assim a proteo contra o rastreamento de suas transaes. Identicadores opacos permitem aos provedores de servios identicar quem so seus clientes, relacionando em suas contas locais, porm no possibilita que os provedores de servios obtenham informaes pessoais dos clientes de forma que possa comprometer a privacidade do mesmo. 1.5.2. Gerenciamento de Polticas de segurana As polticas de segurana descrevem as necessidades e as obrigaes de segurana para um dado domnio de segurana. No ambiente dos Servios Web, comum que um uxo de negcios seja composto por diversos servios presentes em diferentes domnios administrativos e de segurana. Dessa forma, um uxo de negcios pode ser regido por diferentes polticas de segurana e o gerenciamento das mesmas para que a transao ocorra com sucesso e forma segura um desao. Por exemplo, a comunicao de todos os ns de um determinado domnio dever ser cifrada e assinada, garantindo as propriedades bsicas de segurana. Visando remover a complexidade dos ns em ter que trabalhar com uma Infra-estrutura de Chave Pblica (ICP), um nico n do domnio poderia car responsvel pelos processos de cifragem, decifragem, assinatura e vericao de assinaturas. J em um outro caso, tal soluo no seria ideal, visto que desejado garantir uma segurana m-a-m, ou seja, uma vez que a mensagem tenha sido cifrada e/ou assinada pela origem, somente o n destino poder ler e/ou modicar a mesma (diferentes contextos de segurana, apresentados na gura 1.4). Neste caso, a exibilidade para localizao das operaes de segurana tambm deve ser considerada como um requisito da especicao da poltica de segurana. Em ambiente multi-salto, a poltica deve ser exvel o suciente para permitir regras que denam onde dever ocorrer a cifragem, a decifragem, a assinatura ou a vericao da

assinatura. Em [Chang et al. 2003], apresentado um modelo para o gerenciamento de polticas de segurana para ambientes de larga escala compostos por Servios Web. Segundo [Chang et al. 2003], para que uma poltica de segurana garanta um acordo m-a-m, deve-se considerar a interoperabilidade entre as verses das polticas de segurana; garantir a privacidade das partes envolvidas e visar o estabelecimento dinmico das polticas de segurana, visto que as polticas denidas estaticamente podem se tornar inseguras depois de um certo tempo. Porm, se por um lado h necessidade de uma evoluo dinmica das polticas, por outro lado tal fato pode trazer um problema. Em ambientes de larga escala, uma transao pode possuir uma longa durao e mudanas nas polticas de segurana no deveriam interferir nessa transao. Dessa forma, importante tambm considerar a interoperabilidade entre as verses que uma poltica pode assumir. A proposta de [Chang et al. 2003], baseada no uso de um contrato interopervel (Interoperability Contract Document ICD), permite a colaborao entre as partes para estabelecer polticas de segurana dinmicas e individuais para cada operao do servio e prov ainda medidas para o controle de verso e interoperabilidade destas polticas. A Figura 1.18 ilustra os passos envolvidos em uma transao de acordo com o modelo.
1. Registro de perfis

Perfil de Segurana de C

Repositrio de Perfis

Perfil de Segurana de S
2. Obtm perfis

Clculo do 3. Clculo do ICD ICD

Mens.

ICD

4. Envio da mensagem + ICD Mens.

ICD

Mens.

Figura 1.18. O uso do ICD [Chang et al. 2003]

Cada parte, no caso C e S, registram seus pers de segurana no repositrio de pers (passo 1). Cada perl pode estar relacionado a um grupo de servios ou a servios individuais e contm as polticas de segurana, suas preferncias, etc. Tal repositrio est acessvel somente para as partes registradas, no exemplo, para C e S, respectivamente. Uma vez que C queira enviar uma mensagem para S, este aciona o mdulo para o clculo do ICD, o qual obtm os pers de segurana de C e de S no repositrio de pers (passos 2 e 3). O clculo do ICD consiste de uma interseco das preferncias de segurana de ambas as partes. Se o resultado for um conjunto vazio, ento o processo abortado atravs de uma exceo. Por outro lado, se existir mais de um elemento dentro do conjunto, a seleo ser baseada em uma ordem de prioridade, a saber: as preferncias

do receptor; as preferncias do emissor; o nvel de segurana; e o desempenho. Para todas as mensagens que forem enviadas por C, ser anexado o ICD, indicando assim a poltica de segurana aplicada especicamente quela mensagem (passo 4). A mensagem SOAP personalizada de acordo com as informaes de segurana baseadas no ICD. Por exemplo, se para um dado n a credencial de autenticao for requerida, esta ser inserida na parte de autenticao do cabealho SOAP. E, se a integridade for requerida, a mensagem ser assinada e o algoritmo utilizado ser identicado pelo ICD, o mesmo para a cifragem. Por m, na recepo da mensagem, atravs do ICD, S consegue vericar se est de acordo com o combinado. O ICD anexado mensagem possibilita uma evoluo da aplicao sem que isso acarrete problemas de segurana. Dessa forma, quando a verso da poltica de segurana de qualquer parte avanar, um novo ICD recalculado e ser anexado nas prximas mensagens que sairo. Com isso, uma parte consegue aplicar diferentes verses da poltica para interoperar com diferentes parceiros sem ambigidades. Conforme apresentado na Figura 1.18, os pers de segurana de C e de S esto armazenados em um mesmo repositrio, porm previsto no modelo a presena de diversos repositrios, por exemplo, um por domnio administrativo e assim, no clculo do ICD os pers de segurana podem ser obtidos de diferentes repositrios. No trabalho [Chang et al. 2003] no apresentada uma forma para localizar tais repositrios, bem como para saber em qual repositrio estar armazenado o perl de segurana de cada parte. 1.5.3. Gerenciamento de Conana A federao de identidades tem como ponto fundamental as relaes de conana entre provedores de servios e clientes, e entre os prprios provedores de servio. O fornecimento de informaes pessoais de um cliente a um provedor de servio s ocorre depois que o cliente tenha certeza de que suas informaes sero manipuladas de maneira correta. Por outro lado, o provedor de servio s ir conceder ao cliente o acesso ao recurso, se o mesmo conar nas informaes fornecidas pelo cliente. O mesmo ocorre nas relaes de conana entre provedores de servio. Tais relaes permitem, por exemplo, que um usurio autenticado em um determinado provedor possa usufruir dos recursos providos por outro provedor, j que ambos possuem um acordo indicando o compartilhamento de recursos para os usurios de ambos provedores. A seguir, sero apresentados alguns trabalhos que tratam diretamente com o problema da conana, com um enfoque voltado na negociao da conana dentro do ambiente dos Servios Web.

TrustBuilder Em [Winslett et al. 2002], apresentado o sistema TrustBuilder que tem por objetivo permitir o estabelecimento dinmico da conana entre partes estranhas dentro do contexto da Internet. O TrustBuilder permite que as partes, envolvidas na negociao, revelem gradualmente suas credenciais e polticas de controle de acesso para estabelecer a conana

necessria para a realizao da comunicao efetiva entre as partes. Este trabalho est focado na denio de estratgias e protocolos para o estabelecimento da conana. O estabelecimento da conana leva em considerao que cada parte possui polticas de controle de acesso sobre os recursos que deseja proteger. Tais recursos podem ser os servios providos por uma determinada parte ou ainda as credenciais de segurana, como o nmero do documento de identidade, nmero do passaporte, nmero do carto de crdito, etc. As polticas tambm denem quais credenciais especcas, devem ser apresentadas para que se obtenha acesso ao recurso desejado. As estratgias controlam quais e quando as credencias sero reveladas e tambm quando a negociao ser nalizada. Neste caso, as estratgias estaro trabalhando juntamente com as polticas de controle de acesso. J o protocolo indica a ordem das mensagens a serem trocadas, bem como quais informaes devero estar contidas nas mensagens. A revelao gradual das credenciais trata de uma medida preventiva contra partes com quem ainda no exista uma relao de conana. Por exemplo, Joo deseja comprar um produto na empresa XYZ. Para que se possa conrmar a compra, necessrio que Joo fornea o nmero do seu carto de crdito, porm Joo no far isso sem que antes a empresa XYZ fornea informaes de que a mesma trata-se de uma empresa idnea, informao esta que pode ser emitida por um rgo no qual Joo j cona. Neste caso, o problema est em como revelar as credencias de cada parte, sem que isso venha trazer prejuzos caso alguma parte no honre suas obrigaes. Uma soluo para o problema consiste na utilizao de uma Terceira Parte Convel (TPC), em que ambas as partes envolvidas na comunicao, revelam suas credenciais e polticas para a TPC e delegam a esta a tarefa de determinar a conana entre cada parte. Porm, tal soluo torna-se um gargalo em ambientes de larga escala e ainda um ponto nico de vulnerabilidade. O uso do conceito de prova de conhecimento zero conseguiria provar que as credenciais respeitam as polticas sem que seja preciso revelar tanto as credenciais quanto as polticas (o trabalho de [Cattaneo et al. 2004], apresentado anteriormente faz uso deste conceito). Porm, segundo apresentado em [Winslett et al. 2002], tal soluo difcil de ser implementada de forma eciente. O TrustBuilder baseia-se na negociao direta entre as partes, atravs da revelao parcial das credenciais e polticas. Sabendo que cada parte pode possuir diversas polticas e credenciais de segurana, as quais podem ou no ser utilizadas em determinadas negociaes, a medida, considerada por [Winslett et al. 2002] como a melhor alternativa, consiste em somente revelar as polticas necessrias para a comunicao em questo. A Figura 1.19 ilustra um exemplo apresentado em [Winslett et al. 2002]. No passo 1, Joo deseja comprar um produto da empresa XYZ, indicando que quer um desconto no valor nal do produto. A empresa XYZ deniu em suas polticas que somente os clientes que comprovarem que so revendedores podero obter desconto, dessa forma, no passo 2, enviada a poltica P2 para Joo, requerendo uma credencial de revendedor e tambm o nmero do carto de crdito para que se possa efetivar a venda. Por sua vez, Joo tambm possui um poltica local a qual indica que s fornecer seu nmero de carto de crdito a instituies que estejam devidamente regulamentadas

Joo
1. Pedido de compra com desconto 2. XYZ envia sua poltica P2 3. Envia sua poltica P1 + credenciais exigidas em P2 4. Envia as credenciais exigidas em P1 5. Envia credenciais relacionadas ao pagamento 6. Garante o acesso ao servio

XYZ

Figura 1.19. TrustBuilder: negociao de conana

na Federao da Indstria e do Comrcio. Assim, no passo 3 Joo fornece a credencial de que um revendedor juntamente com a sua poltica P1, indicando que XYZ prove que faz parte da Federao da Indstria e do Comrcio. No passo 4, XYZ fornece a credencial exigida por P1 e assim, no prximo passo, Joo fornece o nmero do carto de crdito. Por m, aps a empresa XYZ confrontar as credenciais fornecidas com a sua poltica de controle de acesso, esta garante a Joo a venda do produto. Trust-Serv O Trust-Serv [Skogsrud et al. 2003] uma infra-estrutura voltada para o estabelecimento de conana dentro do ambiente dos Servios Web. O trabalho apresenta um modelo de polticas para o estabelecimento de conana baseado em mquinas de estado [Hopcroft e Ullman 1979]. Neste trabalho, um modelo para o gerenciamento do ciclo de vida das polticas o que permite a evoluo, bem como a migrao, das polticas sem que isso interrompa as negociaes que j estejam em andamento apresentado. A estratgia proposta tambm permite compensar o requisitor, caso os direitos de acesso concedidos a este sejam revogados em uma migrao para uma nova poltica. Segundo [Skogsrud et al. 2003], o Trust-Serv um trabalho complementar ao TrustBuilder [Winslett et al. 2002] e pode ser utilizado para prover o gerenciamento do ciclo de vida das polticas. No Trust-Serv, os estados de uma mquina de estados representam o nvel de conana atingido pelo requisitor e para cada novo estado que o requisitor atingir o acesso a novos recursos ser garantido. Os recursos so denidos como operaes dos Servios Web ou credenciais do prprio provedor de servios. O Trust-Serv ainda adota o conceito de papis [Ferraiolo et al. 2001] e, ao invs de associar os recursos diretamente aos estados, associam-se papis. No modelo, os papis so acumulativos e assim, os papis ativados em um estado anterior no sero desativados ao se atingir um novo estado. J as transaes indicam as condies que um requisitor deve cumprir para que possa sair de um estado e ir para outro. Em [Skogsrud et al. 2003], so propostas extenses s tran-

saes de uma mquina de estado tradicional para capturar as abstraes de segurana, necessrias para o estabelecimento da conana. A arquitetura do Trust-Serv dividida em camadas o que permite separar os mecanismos para o estabelecimento da conana e o controle de acesso (nvel de controle) da lgica de aplicao (nvel de servio). Para cada Servio Web, associado um controlador, o qual intercepta de forma transparente todas as mensagens direcionadas a este servio. Os controladores podem aceitar ou recusar uma invocao ou ainda iniciar uma iterao com o controlador da outra parte para estabelecer um nvel de conana, antes de aceitar a invocao. A Figura 1.20 ilustra a disposio dos controladores na arquitetura do Trust-Serv.
poltica poltica

Nvel de servio Nvel de controle

Requisitor Controlador

Servio Web Controlador

Figura 1.20. TrustServ: Nveis de servio e de controle [Skogsrud et al. 2004]

O trabalho tambm prope solues para o gerenciamento do ciclo de vida das polticas, no caso, o foco do trabalho est direcionado ao contexto das polticas para o estabelecimento da conana entre os Servios Web. A substituio direta de uma poltica que j est sendo empregada por uma nova poltica pode no ser o ideal, visto que isso poderia acarretar no reincio de todas as negociaes que j esto em andamento. O TrustServ prov diferentes estratgias para lidar com estes problemas: coexistncia: permite que a negociao em andamento seja nalizada de acordo com a poltica antiga, porm requer que todas as novas negociaes obedeam a nova poltica; abortamento: aborta todas as negociaes que estejam em andamento; migrao: migra todas as negociaes existentes para a nova poltica, desde que a poltica antiga esteja contida dentro da nova poltica. Dessa forma, todos os estados j visitados e todas as transaes j disparadas na poltica antiga devero estar presentes na nova poltica. As negociaes em andamento que estejam de acordo com essa medida sero migradas para a nova poltica. J as negociaes que no estejam de acordo sero retornadas at atingirem um estado que esteja de acordo com a nova poltica. Em alguns casos, as estratgias Coexistncia e Abortar podem no ser ideais. A coexistncia de duas polticas operando ao mesmo tempo pode no ser desejado, por exemplo, do ponto de vista legal. Clientes estariam recebendo tratamento diferenciados diante, por exemplo, de um mesmo pagamento. J abortar todas as transaes existentes poderiam trazer prejuzos para o provedor do servio, visto que diversos clientes poderiam desistir de tentar recomear toda a negociao novamente. Por outro lado, a estratgia da

migrao consegue unir as vantagens das duas estratgias anteriores. A regresso at um estado que seja comum s duas polticas evita que toda a transao tenha que ser refeita e tambm garante que os prximos estados estaro de acordo com a nova poltica, evitando assim a coexistncia de diferentes polticas.

1.6. Ferramentas para o Desenvolvimento de Servios Web Seguros

Um Servio Web consiste de um componente de software que permite a interao entre aplicaes atravs de uma rede [W3C 2004a]. Em resumo, qualquer aplicao que consiga enviar, receber e processar mensagens SOAP trocadas atravs de algum protocolo de transporte pode ser considerada um Servio Web. Existem hoje diversas ferramentas para o desenvolvimento de aplicaes baseadas na arquitetura dos Servios Web. Algumas destas so ambientes completos para o desenvolvimento e disponibilizao dos servios, como a Java Web Services Development Pack (JWSDP)16 , j outras so s implementaes do SOAP, como o caso do Apache Axis17 e necessitam de outras ferramentas para permitir a disponibilizao dos servios ou mesmo para agregar caractersticas de segurana. As licenas de distribuio destas ferramentas tambm so outro ponto de divergncia. Algumas esto sob licena de cdigo fechado (proprietrio) e exigem o pagamento para o uso de ferramentas, outras possuem uma licena de distribuio gratuita, porm no disponibilizam os cdigos fontes, e, por m, existem ainda as ferramentas sob licena de software livre. Esta seo aborda algumas ferramentas sob licena de software livre, devido natureza destas ser mais adequada ao meio acadmico e por que estas permitem a divulgao do conhecimento atravs da disponibilizao do cdigo e da possibilidade de modicar e redistribuir o mesmo. O Apache Axis uma ferramenta de cdigo aberto que disponibiliza um servidor SOAP juntamente com um conjunto de APIs que facilita o desenvolvimento de aplicaes clientes e de Servios Web. Apesar do Axis apresentar um servidor HTTP prprio para a disponibilizao dos servios, os desenvolvedores geralmente fazem uso do servidor de aplicao Apache TomCat18 , que tambm possui uma licena de cdigo aberto, j que este ltimo mais robusto e completo. Atualmente, o Axis possui duas verses que esto sendo desenvolvidas em paralelo. A verso 1 possui implementaes em Java e em C++, e alm de ser um interpretador SOAP, apresenta ferramentas e APIs para tratar diretamente com documentos WSDL (ver seo 1.3). J a verso 2 do Axis19 , recentemente lanada, s possui a implementao em Java e segundo sua documentao, trata-se de uma completa reestruturao da verso 1, possuindo uma melhor modularidade, mais focada no XML e mais eciente que a verso 1. Porm, a principal diferena que a verso 2 no se resume apenas na implementao das especicaes SOAP 1.1 e SOAP 1.2. Esta verso apresenta tambm uma melhor integrao com as propostas para os Servios Web (como a WS-Security [OASIS 2004c], WS-Coordination [Cabrera et al. 2004], entre outras), permitindo a integrao destas atravs de mdulos de software.
16 http://java.sun.com/webservices/jwsdp 17 http://ws.apache.org/axis 18 http://tomcat.apache.org 19 http://ws.apache.org/axis2

Porm, o Axis no apresenta solues para prover segurana nas aplicaes desenvolvidas com ele. Para isso, a prpria fundao Apache lanou diversas outras ferramentas que implementam as principais especicaes de segurana descritas na seo 1.4. A Apache XMLSecurity20 uma implementao de cdigo aberto para as especicaes XMLDSign e XMLEncryption. Trata-se de um trabalho bem maduro e amplamente aceito, sendo at mesmo utilizado por outras plataformas de desenvolvimento, como a JWSDP da empresa Sun. O projeto Apache WSS4J (WS-Security for Java) uma implementao de cdigo aberto da especicao WS-Security [OASIS 2004c], que consiste de uma biblioteca Java que pode ser usada para assinar e vericar mensagens SOAP que contenham informaes expressas de acordo com a WS-Security. Diferentemente da biblioteca Apache XMLSecurity, a WSS4J est diretamente ligada ao Apache Axis, a XMLSecurity e ainda a biblioteca OpenSAML21 , uma implementao de cdigo aberto para a SAML[OASIS 2005c]. Esto surgindo alguns esforos para agregar WSS4J os conceitos denidos na especicao WS-Trust [WS-Trust 2005], mas a implementao ainda no est to madura quanto as outras bibliotecas apresentadas aqui.

1.7. Concluso
Pode-se dizer que o grande sucesso das aplicaes para Internet se deu devido ao alto nvel de abstrao. Isto permitiu garantir a interoperabilidade entre as mais diversas aplicaes, sistemas operacionais e equipamentos. Os Servios Web exploram esse nvel de abstrao associado a uma lgica de negcios. Neste captulo buscou-se introduzir os conceitos que regem a arquitetura orientada a servios, tendo como foco os Servios Web. Foram apresentados alguns dos desaos de segurana relacionados arquitetura dos Servios Web, bem como alguns trabalhos que visam tratar tais desaos. Como visto, alm das propriedades bsicas de segurana, a concepo de aplicaes baseadas nos Servios Web deve considerar pontos como a transposio de domnios administrativos e de segurana, o que acarreta em preocupaes com a privacidade, o anonimato, a evoluo das polticas de segurana, e principalmente, a interoperabilidade. Para muitos destes desaos, j foram lanadas diversas propostas com o aval de rgos padronizadores, fornecendo assim um ponto de partida comum para que desenvolvedores possam criar suas aplicaes e que as mesmas sero interoperveis. Porm, muitas especicaes para o ambiente dos Servios Web so projetadas para serem estendidas e ainda apresentam diversas formas para expressar a mesma funo, o que permite diferentes interpretaes e como conseqncia, tais caractersticas tornam-se uma barreira contra a interoperabilidade [WS-I 2005]. Por exemplo, a especicao WS-Security introduz muitas opes e escolhas. Se diferentes empresas selecionam diferentes opes, estas podem no mais interoperar, apesar de estarem seguindo a mesma especicao. J existem preocupaes a respeito e o rgo WS-I j est apresentando algumas recomendaes para o uso de padres e tecnologias de segurana para os Servios
20 http://xml.apache.org/security/ 21 http://www.opensaml.org

Web, de forma a garantir a real interoperabilidade entre as implementaes. Enquanto em algumas reas de segurana j existem especicaes consolidadas, mesmo diante de algumas ambigidades, em outras reas, como o gerenciamento de polticas e de conana, embora este captulo tenha apresentado alguns trabalhos, no existem ainda padres de fato, sendo esta um bom ambiente para pesquisa. No stio http://www.das.ufsc.br/seguranca/webservices esto disponveis informaes sobre as recentes pesquisas22 feitas pelo Grupo de Computao Segura e Convel (GCSeg) da UFSC, no contexto do projeto Infra-estrutura de Segurana para Aplicaes Distribudas Orientadas a Servio, que tem apoio do CNPq. Alm disso, tambm esto disponveis documentos tcnicos que detalham como implantar a infra-estrutura necessria para o desenvolvimento e provimento de aplicaes baseadas nos Servios Web, e alguns exemplos de cdigo, estes disponveis sob licenas de software livre.

Referncias
[Amoroso 1994] Amoroso, E. G. (1994). Fundamentals of Computer Security Technology. Prentice Hall. [Asokan et al. 1997] Asokan, N., Schunter, M., e Waidner, M. (1997). Optimistic protocols for fair exchange. In CCS 97: 4th ACM conference on Computer and communications security, pages 717, New York, NY, USA. ACM Press. [Bartel et al. 2002] Bartel, M., Boyer, J., e Fox, B. (2002). XML-Signature Syntax and Processing. W3C. http://www.w3.org/TR/xmldsig-core. [Bishop e Bailey 1996] Bishop, M. e Bailey, D. (1996). A critical analysis of vulnerability taxonomies. Technical Report CSE-96-11, Department of Computer Science at University of California, Davis. [Boyer 2001] Boyer, J. (2001). Canonical XML. W3C. http://www.w3.org/TR/ xml-c14n. [Brown e Kindel 1996] Brown, N. e Kindel, C. (1996). Distributed Component Object Model Protocol DCOM/1.0. Microsoft. [Cabrera et al. 2004] Cabrera, F., Copeland, G., Freund, T., Klein, J., Langworthy, D., Orchard, D., Shewchuk, J., e Storey, T. (2004). Web Services Coordination. Web Services Interoperability Organization. http://msdn.microsoft.com/library/ en-us/dnglobspec/html/WS-Coordination.pdf. [Carmody 2001] Carmody, S. (2001). Shibboleth Overview and Requirements. Shibboleth Working Group. [Cattaneo et al. 2004] Cattaneo, G., Faruolo, P., e Petrillo, U. F. (2004). Providing privacy for web services by anonymous group identication. In International Conference on Web Services (ICWS04). IEEE.
22 [de

Mello et al. 2005, de Mello e da Silva Fraga 2005, Wangham et al. 2005, Wangham et al. 2006]

[Chang et al. 2003] Chang, S., Chen, W., e Hsu, M. (2003). Managing security policy in a large distributed web services environment. In 27th International Computer Software and Applications Conference (COMPSAC03). IEEE. [Char e Mezini 2005] Char, 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 5966. [Daemen e Rijmen 2002] Daemen, J. e Rijmen, V. (2002). The Design of Rijndael: AES - The Advanced Encryption Standard. Springer-Verlag. [Damiani et al. 2003] Damiani, E., di Vimercati, S. D. C., e Samarati, P. (2003). Managing multiple and dependable identities. In IEEE Internet Computing, pages 2937. IEEE. [de Mello e da Silva Fraga 2005] de Mello, E. R. e da Silva Fraga, J. (2005). Mediation of trust across web services. In 3rd IEEE International Conference on Web Services (ICWS05), pages 515522, Orlando, Flrida - EUA. [de Mello et al. 2005] de Mello, E. R., Wangham, M., da Silva Fraga, J., e Rabelo, R. (2005). A secure model to establish trust relationships in web services for virtual organizations. In Camarinha-Matos, L. M., Afsarmanesh, H., e Ortiz, A., editors, 6th IFIP Working Conference on Virtual Enterprises (PRO-VE05), pages 183190, Valncia, Espanha. Springer. [Demchenko et al. 2005] Demchenko, Y., Gommans, L., de Laat, C., e Oudenaarde, B. (2005). Web services and grid security vulnerabilities and threats analysis and model. http://www.uazone.org/demch/analytic/ draft-grid-security-incident-04.pdf. [Dierks e Allen 1999] Dierks, T. e Allen, C. (1999). The TLS Protocol Version 1.0. IETF RFC 2246. [Eastlake e Jones 2001] Eastlake, D. e Jones, P. (2001). US Secure Hash Algorithm 1 (SHA1). Internet Engineering Task Force RFC 3174. [Ellison et al. 1999] Ellison, C. M., Frantz, B., Lampson, B., Rivest, R., Thomas, B. M., e Ylonen, T. (1999). SPKI Certicate Theory. Internet Engineering Task Force RFC 2693. [Ferraiolo et al. 2001] Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., e Chandramouli, R. (2001). Proposed NIST standard for role-based access control. ACM Transactions on Information and System Security, 4(3):224274. [Freier et al. 1996] Freier, A. O., Karlton, P., e Kocher, P. C. (1996). The SSL protocol v.3. Internet Draft. [Goldwasser et al. 1989] Goldwasser, S., Micali, S., e Rackoff, C. (1989). The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18(1):186208.

[Hallam-Baker e Mysore 2005] Hallam-Baker, P. e Mysore, S. H. (2005). XML Key Management Specication (XKMS 2.0). W3C Proposed Recommendation. [Hopcroft e Ullman 1979] Hopcroft, J. e Ullman, J. (1979). Introduction to Automata Theory, Languages and Computation. Addison-Wesley. [Housley et al. 2002] Housley, R., Polk, W., Ford, W., e Solo, D. (2002). Internet X. 509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole. IETF RFC 3280. [Hung et al. 2004] Hung, P. C. K., Ferrari, E., e Carminati, B. (2004). Towards standardized web services privacy technologies. In International Conference on Web Services (ICWS04). IEEE. [IBM e Microsoft 2002] IBM e Microsoft (2002). Security in a Web Services World: A Proposed Architecture and Roadmap. IBM Corporation and Microsoft Corporation. http://msdn.microsoft.com/ws-security/. [Imamura et al. 2002] Imamura, T., Dillaway, B., e Simon, E. (2002). XML Encryption Syntax and Processing. W3C. http://www.w3.org/TR/xmlenc-core. [Jsang et al. 2005] Jsang, A., Fabre, J., Hay, B., Dalziel, J., e Pope, S. (2005). Trust requirements in identity management. In CRPIT 44: Proceedings of the 2005 Australasian workshop on Grid computing and e-research, pages 99108, Darlinghurst, Australia. Australian Computer Society, Inc. [Jsang e Pope 2005] Jsang, A. e Pope, S. (2005). User centric identity management. In AusCERT Asia Pacic Information Technology Security Conference 2005. [Kohl e Neuman 1993] Kohl, J. e Neuman, C. (1993). The Kerberos Network Authentication Service (v5). Internet Engineering Task Force RFC 1510. [Landwehr 2001] Landwehr, C. E. (2001). Computer Security. In International Journal of Information Security, volume 1, pages 313. Springer-Verlag Heidelberg. [Liberty 2003a] Liberty (2003a). Introduction to the Liberty Alliance Identity Architecture. Liberty Alliance. [Liberty 2003b] Liberty (2003b). Privacy and Security Best Practices. Liberty Alliance. [Lorch et al. 2003] Lorch, M., Proctor, S., Lepro, R., Kafura, D., e Shah, S. (2003). First experiences using xacml for access control in distributed systems. In ACM Workshop on XML Security. [OASIS 2002] OASIS (2002). Universal Description, Discovery and Integration v2 (UDDI). Organization for the Advancement of Structured Information Standards (OASIS). [OASIS 2004a] OASIS (2004a). Introduction to UDDI: Important features and functional concepts. Organization for the Advancement of Structured Information Standards (OASIS). http://uddi.org/pubs/uddi-tech-wp.pdf.

[OASIS 2004b] OASIS (2004b). Universal Description, Discovery and Integration v3.0.2 (UDDI). Organization for the Advancement of Structured Information Standards (OASIS). [OASIS 2004c] OASIS (2004c). Web Services Security: SOAP Message Security 1.0. OASIS. http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0.pdf. [OASIS 2005a] OASIS (2005a). eXtensible Access Control Markup Language (XACML) version 2.0. Organization for the Advancement of Structured Information Standards (OASIS). http://docs.oasis-open.org/xacml/2.0/access_ control-xacml-2.0-core-spec-os.pdf. [OASIS 2005b] OASIS (2005b). SAML Executive Overview. Organization for the Advancement of Structured Information Standards (OASIS). [OASIS 2005c] OASIS (2005c). Security Assertion Markup Language (SAML) 2.0 Technical Overview. Organization for the Advancement of Structured Information Standards (OASIS). [OMG 2002] OMG (2002). The Common Object Request Broker Architecture v3.0.2. Object Management Group (OMG). [OpenGroup 1997] OpenGroup (1997). DCE 1.1: Remote Procedure Call. Open Group Technical Standard, AE Specication C309. [Papazoglou 2003] Papazoglou, M. P. (2003). Service-oriented computing: Concepts, characteristics and directions. In Fourth International Conference on Web Information systems Engineering (WISE03). [Parr e Villars 2001] Parr, B. e Villars, R. (2001). Digital identity: The coming struggle for the future of the net. Boletim 24929, IDC. [Rannenberg 2000] Rannenberg, K. (2000). Multilateral security a concept and examples for balanced security. In Workshop on New security paradigms (NSPW00), pages 151 162, New York, NY, USA. ACM Press. [Rivest e Lampson 1996] Rivest, R. L. e Lampson, B. (1996). SDSI A simple distributed security infrastructure. Presented at CRYPTO96 Rumpsession. [RSA 2002] RSA (2002). PCKS#1 v2.1: RSA Cryptography Standard. RSA Laboratories. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1. pdf. [RSS 2005] RSS (2005). Really Simple Syndication. http://www.rssboard.org/ rss-specification. [Russell e Gangeni 1991] Russell, D. e Gangeni, G. (1991). Computer Security Basics. OReilly Associates Inc.

[Santis et al. 1998] Santis, A. D., Crescenzo, G. D., e Persiono, G. (1998). Communication-efcient anonymous group identication. In 5th A.C.M. Conference on Computer and Communications Security (ACM CCS98), pages 7382, San Francisco, California, U.S.A. [Shibboleth 2005] Shibboleth (2005). Shibboleth Architecture. http://shibboleth.internet2.edu/docs/ draft-mace-shibboleth-tech-overview-latest.pdf. [Skogsrud et al. 2003] Skogsrud, H., Benatallah, B., e Casati, F. (2003). Modelo-driven trust negotiation for web services. In IEEE Internet Computing, pages 4552. IEEE Computer Society. [Skogsrud et al. 2004] Skogsrud, H., Benatallah, B., e Casati, F. (2004). Trust-serv: model-driven lifecycle management of trust negotiation policies for web services. In WWW 2004, pages 5362. ACM. [Sun 2002] Sun (2002). Java remote method invocation specication. Revision 1.8 Java 2 SDK. [Vogels 2003] Vogels, W. (2003). Web services are not distributed objects. Internet Computing, 7(6):5966. [W3C 2001] W3C (2001). Web Services Description Language 1.1. W3C Working Group. [W3C 2002] W3C (2002). The Platform for Privacy Preferences 1.0 (P3P1) Specication. W3C Recommendation. http://www.w3c.org/TR/P3P. [W3C 2003] W3C (2003). SOAP 1.2 W3C Recommendation. W3C. http://www. w3.org/TR/soap12. [W3C 2004a] W3C (2004a). Web Services Architecture. W3C Working Group. http: //www.w3.org/TR/2004/NOTE-ws-arch-20040211. [W3C 2004b] W3C (2004b). Web Services Architecture Requirements. W3C Working Group. http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211. [Wangham et al. 2006] Wangham, M., da Silva Fraga, J., de Mello, E. R., e Milanez, J. (2006). Um modelo para o gerenciamento federado do spki/sdsi atravs do servio xkms. In VI Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais (SBSEG06), Santos, SP - Brasil. [Wangham et al. 2005] Wangham, M. S., Mello, E., Rabelo, R., e da Silva Fraga, J. (2005). Provendo garantias de segurana para formao de organizaes virtuais. In Gerrini, F. M., editor, Gesto Avanada de Manufatura, volume 2, pages 7584. Editora Novos Talentos. [Weerawarana et al. 2005] Weerawarana, S., Curbera, F., Leymann, F., Storey, T., e Ferguson, D. F. (2005). Web Services Plataform Architecture. Prentice Hall.

[Wege 2002] Wege, C. (2002). Portal server technology. IEEE Internet Computing, 6(3):7377. [Westbridge 2003] Westbridge (2003). Securing and Managing XML Web Services Guide to XML Web Services Security. Westbridge Technology Inc. [Winslett et al. 2002] Winslett, M., Yu, T., Seamons, K. E., Hess, A., Jacobson, J., Jarvis, R., Smith, B., e Yu, L. (2002). Negotiating trust on the web. In IEEE Internet Computing, number 6 in 6, pages 3037. IEEE Computer Society. [WS-Federation 2003a] WS-Federation (2003a). Web Services Federation Language. http://msdn.microsoft.com/ws/2003/07/ws-federation. [WS-Federation 2003b] WS-Federation (2003b). WS-Federation: Active Requestor Prole. ftp://www6.software.ibm.com/software/developer/ library/ws-fedact.pdf. [WS-Federation 2003c] WS-Federation (2003c). WS-Federation: Passive Requestor Prole. ftp://www6.software.ibm.com/software/developer/ library/ws-fedpass.pdf. [WS-I 2005] WS-I (2005). Basic Security Prole Version 1.0. Web Services Interoperability Organization. http://www.ws-i.org/Profiles/ BasicSecurityProfile-1.0-2005-08-29.html. [WS-Policy 2004] WS-Policy (2004). Web Services Policy Framework. msdn.microsoft.com/ws/2004/09/policy/. http://

[WS-PolicyAttachment 2004] WS-PolicyAttachment (2004). Web Services Policy Attachment. http://msdn.microsoft.com/ws/2004/09/ policyattachment. [WS-SecureConversation 2005] WS-SecureConversation (2005). Web Services Secure Conversation Language. [WS-SecurityPolicy 2005] WS-SecurityPolicy (2005). Language. Web Services Security Policy

[WS-Trust 2005] WS-Trust (2005). Web Services Trust Language (WS-Trust). http://msdn.microsoft.com/library/en-us/dnglobspec/html/ WS-Trust.asp. [Wu 1998] Wu, T. (1998). The secure remote password protocol. In Internet Society Network and Distributed System Security Symposium, pages 97111. [Yavatkar et al. 2000] Yavatkar, R., Pendarakis, D., e Guerin, R. (2000). A Framework for Policy-based Admission Control. IETF RFC 2753. [Zimmerman 1994] Zimmerman, P. (1994). PGP Users Guide. Massachusetts Institute of Technology.