C.E.S.A.R.

CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

Segurana em Web Services: Anlise de WS-Security, WSPolicy e SAML

RICARDO MARINHO DE MELO

Recife 2012

SEGURANA EM WEB SERVICES: ANLISE DE WSSECURITY, WS-POLICY E SAML

Monografia apresentada ao programa de Especializao em Engenharia de Software do Centro de Estudos e Sistemas Educacionais do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Especialista em Engenharia de Software com nfase em Segurana da Informao. Orientao: Prof. Vinicius Cardoso Garcia

Recife 2012

AGRADECIMENTO
Agradeo, inicialmente, a Deus, pela vida. Agradeo a todos os professores que, de alguma forma, contriburam para a concretizao da minha ps-graduao.

Agradeo todas as dificuldades que enfrentei; no fosse por elas, eu no teria sado do lugar. As facilidades nos impedem de caminhar. Mesmo as crticas nos auxiliam muito. (Chico Xavier)

RESUMO
A presente monografia pretende introduzir ao leitor conceitos sobre os Web Services, contemplando aquisies a respeito dos mecanismos de segurana aplicados, em particular os padres WS-Policy, WS-Security e SAML destacando suas aplicabilidades atravs de um estudo de caso que visa avaliar as propriedades de identificao, autenticao, integridade, privacidade e no-repdio destes padres de segurana. O estudo de caso demonstra uma utilizao prtica das especializaes WS-Security, WS-Policy e SAML, utilizada a ferramenta Apache Extensible Interaction System 2.

Palavras-chave: Segurana, Internet, Web Services, WS-Policy, WS-Security, SAML.

ABSTRACT
This monography intends to introduce the reader in the concepts of Web services, covering acquisitions regarding to the security mechanisms applied, in special WS-Policy, WS-Security and SAML highlighting its applicability in a case study that aims to evaluate the properties of identification, authentication, integrity, privacy and non-repudiation of these security standards. The case study demonstrates a practical use of WS-Security, WSPolicy and SAML specialization. The Apache Extensible Interaction System 2 toll was used.

KEYWORDS: Security, Internet, Web Services, WS-Policy, WS-Security and SAML.

LISTA DE ABREVIATURAS E SIGLAS

B2B CORBA DTD FTP GUI HTML HTTP IDE IDL IETF OASIS POJO RPC SAML SGML SMTP SOA SOAP SGML SSL TCP TSL UDDI URI URL W3C WS WSDL WS-Policy WS-Security Web XML XSD Business-to-business Common Object Request Broker Architecture Document Type Definition File Transfer Protocol Graphical User Interface Hyper Text Markup Language Hyper Text Transfer Protocol Integrated Development Environment Interface Definition Language Internet Engineering Task Force Organization for the Advancement of Structured Information Standards Plain Old Java Objects Remote Procedure Call Security Assertion Markup Language Standard Generalized Markup Language Simple Mail Transfer Protocol Service-Oriented Architecture Simple Object Access Protocol Standard Generalized Markup Language Security Socket Layer Transmission Control Protocol Transport Security Layer Universal Description Discovery and Integration Uniform Resource Identifier Uniform Resource Locator World Wide Web Consortium Web Service Web Services Description Language Web Services-Policy Web Services-Security World Wide Web eXtensible Markup Language XML Schema Definition

LISTA DE FIGURAS

FIGURA 1 Relaes entre entidades (W3C, 2004a) .............................................. 13 FIGURA 2 Arquitetura de normas de WS proposta pelo W3C (W3C, 2004a) ...... 15 FIGURA 3 Estrutura de uma mensagem SOAP (W3C, 2003a) ............................. 16 FIGURA 4 Estrutura de um documento WSDL (W3C, 2006) ............................... 18 FIGURA 5 Mensagem SOAP ilustrando o WS-Security (OASIS, 2004c) ............. 22 FIGURA 6 Sintaxe do XML Digital Signature (Hendricks, 2002) ........................ 24 FIGURA 7 Formas de assinatura XML Digital Signature (Bartel, 2002) ............. 24 FIGURA 8 Estrutura da XML Encryption (Hendricks, 2002) ............................... 26 FIGURA 9 Documento XML sem criptografia (Hendricks, 2002) ........................ 27 FIGURA 10 Documento XML com criptografia (Hendricks, 2002) ..................... 27 FIGURA 11 Assero SAML de autenticao (OASIS, 2005b) ............................ 30 FIGURA 12 - Assero SAML de atributos (OASIS, 2005b) .................................. 31 FIGURA 13 Assero SAML de autorizao (OASIS, 2005b) ............................. 32 FIGURA 14 Documento Estrutura simplificada para expressar polticas (WS-Policy, 2006) ...................................................................................................... 34 FIGURA 15 Estrutura da WS-Policy de um servio (WS-SecurityPolicy, 2005) ... 35 FIGURA 16 Arquitetura do Apache Axis 2 (APACHE, 2011) .............................. 37 FIGURA 17 Arquitetura em Camadas (Potts, 2003)......................................38 FIGURA 18 Diagrama de Seqncia da Arquitetura Axis (APACHE, 2011) ....... 39

SUMRIO
1. INTRODUO .......................................................................................................9 1.1 MOTIVAO ........................................................................................................ 10 1.2 JUSTIFICATIVA ................................................................................................... 10 1.3 REA CIENTFICA .............................................................................................. 11 1.4 OBJETIVOS ......................................................................................................... 11 1.5 ESTRUTURA DA DISSERTAO ........................................................................... 11 2. WEB SERVICES ...................................................................................................13 2.1 2.2 2.3 2.4 2.5 2.6 3. ARQUITETURA DOS WEB SERVICES ..................................................................... 13 NORMALIZAO .................................................................................................. 14 XML ................................................................................................................... 15 SOAP .................................................................................................................. 16 WSDL ................................................................................................................. 17 UDDI .................................................................................................................. 19

WS-SECURITY .....................................................................................................20 3.1 ARQUITETURA DO WS-SECURITY ......................................................................... 20 3.2 XML DIGITAL SIGNATURE .................................................................................. 22 3.3 XML ENCRYPTION .............................................................................................. 24

4. 5.

SAML......................................................................................................................28 WS-POLICY ..........................................................................................................32 5.1 POLTICAS PARA WEB SERVICES ......................................................................... 32 5.2 WS-SECURITYPOLICY ......................................................................................... 33

6.

ESTUDO DE CASO ..............................................................................................37 6.1 6.2 6.3 6.4 6.5 APRESENTAO................................................................................................... 37 ARQUITETURA DO SISTEMA ................................................................................. 38 METODOLOGIA .................................................................................................... 39 IMPLEMENTAO ................................................................................................ 40 ANLISE DO ESTUDO DE CASO ............................................................................ 41

7.

CONSIDERAES FINAIS ................................................................................53

REFERNCIAS ............................................................................................................55 ANEXO A ARQUIVOS FONTES ...............................................................................57

1. Introduo
A internet assumiu seu lugar como um importante veculo de comunicao e em pouco tempo tornou-se meio para realizao de negcios, por meio de sua capacidade de atendera os mais diversos sistemas computacionais. O xito deste ambiente to heterogneo foi possvel devido o uso de protocolos padronizados, capazes de garantir interoperabilidade entre as aplicaes, de modo que no importasse qual sistema operacional ou arquitetura de mquina estivesse rodando (Potts, 2003). O advento da Web se deu em meio a um universo de empresas com seus peculiares sistemas computacionais, sistemas esses que quando desenvolvidos no visavam interoperabilidade como, por exemplo, com os sistemas computacionais de seus clientes (Potts, 2003). A partir dessa necessidade de interao entre diferentes aplicaes, surge uma nova caracterizao de sistemas distribudos que possibilita o cmbio de dados e integrao de sistemas j existentes: os Web Services. Os Web Services (W3C, 2004a) utilizam padres neutros como HTTP e XML, permitindo que as diferentes aplicaes sejam integradas atravs de linguagens e protocolos largamente aceitos, garantindo assim interoperabilidade. Organizaes como W3C1 e OASIS2 tem por objetivo projetar e publicar especificaes, ou padres, que cumprem a promessa dos Web Services: interoperabilidade entre as barreiras geogrficas, de hardware, de sistema operacional, de linguagem de programao e integrao de plataformas a baixo custo (Potts, 2003). Contudo, a segurana na transio de dados tornou-se alvo de estudo porque no universo de Web Services que vai alm da transmisso de dados, segurana significa mais do que inviolabilidade de informao. A segurana, nesse contexto, caracteriza-se por uma gama de propriedades onde identificao, autenticao, integridade, privacidade e no-repdio esto inclusas. Para garantir a segurana nos Web Services, algumas tecnologias foram criadas, entre elas, SAML3, WS-Policy4 e WS-Security5, de forma que as suas especificaes tornaram-se indispensveis para a construo de Web Services seguros.
1 2

http://www.w3.org http://www.oasis.open.org 3 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 4 http://www.w3.org/Submission/WS-Policy/ 5 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

Neste contexto, com base na importncia da segurana nos Web Services (HENDRICKS, 2002), este trabalho tem por objetivo estudar os mecanismos de segurana utilizados como padro nos Web Services, definindo, analisando, caracterizando e demonstrando a aplicabilidade, atravs de um estudo de caso, as tecnologias: SAML, WS-Policy e WS-Security.

1.1 Motivao
O crescimento e a complexidade da infraestrutura da Internet e redes corporativas fizeram com que vrios modelos e propostas para a comunicao entre aplicaes fossem apresentados como opo para ambientes empresariais e sistemas distribudos. Com toda esta infraestrutura de tecnologia disponvel, os Web Services esto se tornando uma nova opo de negcio para as empresas que planejam utilizar a Internet e redes corporativas como meio de compartilhamento de informaes. A segurana um elemento indispensvel para a construo e desenvolvimento de uma infraestrutura confivel. No entanto, garantir a segurana dos Web Services representa um desafio devido s limitaes dos padres e necessidade de dar suporte a uma considervel demanda de servios (Potts, 2003). Motivado pelas vantagens dos servios Web e a segurana exigida dos mesmos na construo de aplicaes que usam esses servios delinearam o principal objetivo deste trabalho que estudar os mecanismos utilizados como padro de segurana nos servios Web: WS-Security, SAML e WS-Policy.

1.2

Justificativa
O presente trabalho justifica-se, primeiramente, pela necessidade de normas de

segurana para especificao de mecanismos de proteo para que os Web Services possam contemplar os valores necessrios garantia da segurana na sua utilizao. Contudo, j existem padres promissores para segurana, em especial o padro WSSecurity (OASIS, 2004c), oferecendo mecanismos padro de segurana necessrios para realizar o intercmbio seguro de mensagens certificadas em um ambiente de Web Services, atravs de assinaturas digitais e criptografia. O padro WS-Policy (WSPOLICY, 2006), que prov um modelo de propsito geral para descrever polticas da segurana e por fim o framework SAML (OASIS, 2005c), define uma forma padro

10

para criar, trocar e interpretar asseres de segurana entre entidades de uma aplicao distribuda. Este trabalho avalia um estudo de caso real com desenvolvimento de um prottipo para anlise da tecnologia de servios seguros propostos pelas normas: WSSecurity, WS-Policy e SAML. A importncia mais significativa desse trabalho o retrato atual da tecnologia de Web Services, com uma anlise aprofundada das normas e implementaes de segurana propostas.

1.3

rea Cientfica
A rea cientfica deste trabalho so os sistemas de informao no mbito da

segurana de sistemas distribudos.

1.4

Objetivos
Este trabalho tem como principal objetivo realizar a anlise das normas e

implementaes de segurana para Web Services e dos resultados obtidos no estudo de caso. Estes objetivos foram decomposto nos seguintes objetivos especficos: Estudo da plataforma tecnolgica de Web Services, com nfase nas normas de segurana em nvel de mensagem; Avaliao de um estudo de caso real com desenvolvimento de um prottipo para anlise da tecnologia de servios seguros propostos pelas normas SAML, WSSecurity e WS-Policy.

1.5

Estrutura da Dissertao
A presente dissertao encontra-se organizada em sete captulos que, de certa

forma, mostram a sequncia que foi seguida ao longo deste trabalho, sequncia esta que est delimitada pela Introduo (captulo 1) e Concluses e Trabalhos Futuros (captulo 7). Captulo 1 Introduo motivao, justificativa, rea cientfica, objetivo e estrutura da dissertao; Captulo 2 Web Services levantamento das normas e implementaes de referncia da plataforma de Web Services; Captulo 3 WS-Security definio das especificaes de segurana proposto pelo framework WS-Security; 11

Captulo 4 SAML definio das especificaes de segurana proposto pelo framework SAML; Captulo 5 WS-Policy definio das especificaes de polticas de segurana proposto pelo framework WS-Policy; Captulo 6 Estudo de caso apreciao dos resultados obtidos com o prottipo do estudo de caso no que respeita ao desenvolvimento das tecnologias WS-Security, WS-Policy e SAML;

Captulo 7 Concluses e Trabalhos Futuros apresentao das concluses, os trabalhos futuros e os comentrios finais.

12

2. Web Services
Um Web Service uma aplicao de software que possui interface bem definida e descrita em XML (eXtensible Markup Language), classificada como um tipo especfico de servio. Esses servios so identificados atravs de um URI (Uniform Resource Identifier ou identificador uniforme de recursos), e chamadas atravs das RPCs (Remote Procedure Call ou chamadas de procedimento remoto), como acontece em outros servios distribudos. O tipo de informao oferecida pelos Web Services o que os tornam diferentes de sites Web comuns (W3C, 2004a). O grande entusiasmo em torno dos Web Services baseado na promessa de interoperabilidade entre aplicaes. As interaes com outras aplicaes so realizadas pela troca de mensagens XML em um formato SOAP especfico, utilizando padres da Internet. Os Web Services no so a primeira tecnologia a nos permitir isto, mas so diferentes das tecnologias existentes, pelo fato de usarem padres neutros de plataforma, como HTTP e XML. Atualmente, as vantagens dos Web Services so atrativas para muitas aplicaes, oferecendo flexibilidade e interoperabilidade sobre outras tecnologias. Entre essas vantagens, encontra-se a integrao prpria para business-to-business (B2B). No entanto, essas aplicaes precisam de algum nvel de segurana necessrio para que as mesmas se interconectem de forma confivel. Desta forma, a segurana tem sido considerada um obstculo na adoo dos Web Services.

2.1

Arquitetura dos Web Services

A gesto da arquitetura dos WS (Web Services) fornecida pelo modelo terico

da Service-Oriented Architecture (SOA). Trata-se de um modelo simples que contm trs entidades e trs operaes. A Figura 1 ilustra esse modelo (Potts, 2003).

FIGURA 1 - Relaes entre entidades (W3C, 2004a) 13

O Provedor de servios: responsvel por duas atividades: a primeira publicar as interfaces dos servios providos e a segunda atender as requisies originadas pelos clientes.

O cliente: aps a consulta no diretrio para registro de servios e se o servio foi encontrado, invoca o servio diretamente requisitando o provedor de servios.

O diretrio para registro de servios: o repositrio responsvel por informar

ao cliente a descrio dos servios e a localizao das interfaces dos mesmos. As entidades interagem atravs de trs operaes fundamentais: publicar, localizar, invocar. Inicialmente, o provedor de servios publica as interfaces no diretrio para registro de servios, onde ficaro registrados os servios. Aps a publicao, o cliente poder fazer uma consulta de um determinado servio, se esse servio for localizado no diretrio para registro de servios, o cliente poder invocar o mesmo ao provedor de servios toda vez que desejar us-lo.

2.2

Normalizao
A normalizao da plataforma de Web Services surge com o principal objetivo

de orientar o desenvolvimento de WS de maneira a manter a interoperabilidade. Um documento publicado pela Web Services Interoperability Organization6 (WS-I), organizao responsvel pela manuteno da normalizao da interoperabilidade, abrange uma srie de recomendaes a serem adotadas para o desenvolvimento de WS. A pilha de protocolos dos Web Services apresentada na Figura 2 abrange normas que suportam a interao das trs entidades mencionadas. Algumas dessas mais importantes normas de WS so definidas pelo W3C (W3C, 2004a).

http://www.ws-i.org

14

FIGURA 2 - Arquitetura de normas de WS proposta pelo W3C (W3C, 2004a) A seguir, cada um dos padres XML, SOAP, WSDL e UDDI que compem a pilha bsica de protocolos e tecnologia base dos WS so explicados em detalhes.

2.3

XML
A eXtensible Markup Language (XML) um formato de texto simples e

flexvel, um subconjunto de SGML. Criado em 1996 e formalizado em 1998, se tornou um importante padro de troca de dados na Web. O padro de XML registrado pelo W3C. Com o advento do XML, tornou-se simplificada a tarefa de preparar documentos para troca entre sistemas de diferentes ambientes. A especificao XML contm um conjunto de regras de sintaxe para descrio de dados que definida por uso de Schemas, norma do W3C, que contm regras de validao dos elementos e atributos de um documento XML. Outro componente muito importante so os namespaces, mantido pela W3C. Os namespaces descrevem uma coleo de nomes, identificados por uma referncia URI, que so usados para definir tipos de elementos e atributos de um documento XML. O uso de namespaces previne que documentos XML diferentes tenham elementos como nomes conflitantes. Assim, pode-se atribuir um prefixo ao namespaces.

15

Os componentes schemas e namespaces se interagem para suportar suas aplicaes, permitindo a criao de sistemas que manipulem facilmente informaes entre aplicaes e validadas de uma maneira mais padronizada.

2.4

SOAP
O protocolo de comunicao SOAP uma linguagem XML para troca de

mensagens. Baseia-se em normas como o XML Namespace e XML Schema, que permite independncia de linguagem e que trabalha com diversos sistemas operacionais e sobre protocolos de aplicao j consolidados, com o HTTP, o FTP, o SMTP etc. As facilidades providas pelo HTTP e obviamente o que predomina no uso da WEB, tornouse comum nas implementaes de Web Services. O SOAP uma das normas mais importantes dos Web Services, definida pelo consrcio W3C (W3C, 2003). A norma SOAP define a estrutura de documentos XML, proporcionando simplicidade e coerncia para que uma aplicao envie mensagens XML para outra, garantindo a independncia do transporte utilizado. Uma mensagem SOAP um documento XML. A Figura 3 ilustra a estrutura de uma mensagem SOAP e, em seguida, ser realizado o estudo dos elementos que constitui sua estrutura.

FIGURA 3 Estrutura de uma mensagem SOAP (W3C, 2003a) Envelope SOAP: a mensagem SOAP fornece um envelope (SOAP Envelope) como elemento raiz, este envelope um container7 que protege os dados XML.
7

rea delimitada e protegida destinada para armazenar algo.

16

Tendo como principal objetivo no s proteger os dados mas, alm disso, possibilita transmisso da mensagem SOAP por qualquer protocolo de transporte. O envelope composto por duas partes: o cabealho (SOAP Header) e o corpo (SOAP Body) da mensagem. Cabealho SOAP (SOAP Header): um elemento opcional e o primeiro elemento filho do envelope. O cabealho da mensagem SOAP contm informaes, divididas em blocos, podendo conter zero ou mais blocos de cabealhos. Essas informaes ou diretivas so usadas para gerenciar ou prover segurana, tal como asseres de autorizao e autenticao entre outros.

Corpo SOAP (SOAP Body): um elemento obrigatrio e contm a mensagem

propriamente dita chamada carga til (Payload). O corpo contm os dados de negcio da mensagem ou qualquer tipo de informao XML. No corpo, tambm pode estar contido o elemento Fault, que tem por objetivo transportar informaes sobre erros que possam vir a ocorrer no processamento dessas informaes.

2.5

WSDL
A Web Services Description Language (WSDL) (W3C, 2006) uma gramtica

em XML para definir e especificar as interfaces de um WS. Essas interfaces contm informaes do tipo, localizao do servio, o que o servio pode fazer e como poder ser chamado, permitindo assim, a interao do servio. A WSDL uma linguagem padro usada para descrever as funcionalidades de um WS, independente de linguagem e plataforma (W3C, 2006). Tem como objetivo descrever os servios publicados pelos provedores e que, posteriormente, sero acessados pelos clientes. O WSDL codificado em XML Schema que obedece a uma estrutura fixa para especificar interface de servio. WSDL descrevem um WS em duas fases fundamentais: um abstrato e um concreto (W3C 2006). A parte abstrata descreve as capacidades do WS, em termo de mensagem que este consome e produz. A parte concreta desempenha as mesmas tarefas da Inteface Definition Language (IDL) na CORBA8, prover vnculo da interface, definindo um contrato concreto para vincular fisicamente o cliente ao WS. Os principais elementos XML de um documento WSDL apresentados na Figura 4 so:
8

http://www.corba.org

17

FIGURA 4 Estrutura de um documento WSDL (W3C, 2006) definitions: este o elemento raiz a partir do qual os demais so definidos. types: define os tipos de dados, utilizando o XML Schema, ao longo do documento e que sero utilizados entre o servidor e o cliente durante a comunicao. Os tipos de dados so definidos dentro deste elemento para que sejam posteriormente utilizados no elemento message. message: define, de forma abstrata, as mensagens que sero trocadas, contendo os parmetros de entra e sado do servio. operation: este elemento representa a interao particular com o servio, descrevendo as mensagens de entrada, sada e excees possveis e permitidas. portType: descreve um conjunto abstrato de operaes mapeadas para suporta um ou mais servios. A cada operao, esto associados um pedido e uma resposta. binding: este elemento especifica a ligao de cada elementos abstrato, operaes, mensagens e tipos de dados, com protocolo de rede que sero utilizados para transportar os elementos at o destino. port: associa o elemento binding e o endereo de rede para prover assim um endereo nico para acessar um servio.

service: descreve onde o servio est disponvel ou publicado, associando entre

o elemento binding e o endereo de rede onde o servio pode ser encontrado, possuindo assim um conjunto de port associados. 18

2.6

UDDI
O Universal Description, Discovery and Integration (UDDI) (OASIS, 2004b)

permite que Web Services disponveis na Internet sejam facilmente encontrados, provendo uma interface para utilizao do cliente. Trata-se de um protocolo para registrar, publicar e descobrir WS num ambiente distribudo. Os dados e metadados dos WS so registrados e armazenados em diretrios UDDI registry. Associando a cada estrutura de dados um identificador nico, chamado UDDI key, cada empresa ou organizao, cria suas prprias regras de classificao. A importncia de cada empresa possuir sua classificao permite que clientes realizem consultas mais refinadas, escolhendo o servio que melhor lhe atende. Os diretrios UDDI no armazenam informaes relativas implementao de um WS, como a WSDL do servio. Este tambm contm informaes relativas empresa responsvel que prover o servio. A disponibilidade dos servios dos WS atravs de UDDI no obrigatria (OASIS, 2004c). No domnio de informao da UDDI, existem trs tipos de informao que podem ser consagrados no registro UDDI: Pginas Amarelas: aqui, so includos dados gerais como a entidade fornecedora ou os servios oferecidos. Assim, estes dados so classificados como categorias (i.e. pas de origem, a indstria, o produto, entre outros). A pesquisa um Web Service, neste contexto, feita com base nas categorias. Pginas Brancas: onde, so includas informaes bsicas de contatos que permite pesquisar um WS com base em dados atrelados entidade fornecedora do WS. Essas informaes so constitudas (i.e. nome de um negcio, descrio do negcio, informao de contato, endereo, fax, ou mesmo incluir identificadores de negcios). Pginas Verdes: contm um conjunto de informaes tcnicas sobre um WS, desta forma o programador ao ter acesso essas informaes poder desenvolver sua aplicao que utilize ao WS em questo. Neste captulo, foram descritas algumas das mais importantes normas que constitui a arquitetura dos Web Services. Vimos como os Web Services podem ser usados para integrar diferentes aplicaes. Vimos tambm algumas organizaes responsveis por controlar as principais normas dos Web Services. 19

3. WS-Security
O WS-Security suporta, integra e unifica vrios modelos, mecanismos e tecnologias de segurana, oferecendo mecanismos padro de segurana necessrios para realizar o intercmbio seguro de mensagens certificadas em um ambiente de Web Services. Novas especificaes de segurana definem um conjunto de padres para extenses de cabealhos de mensagens SOAP, utilizados para oferecer maior integridade, confidencialidade e autenticidade. Essas especificaes de segurana so garantidas atravs do uso da Assinatura XML (XML Signature), da Criptografia XML (XML Encryption) e da Autenticao e Autorizao XML (SAML).

3.1

Arquitetura do WS-Security
A arquitetura do padro WS-Security construda sob a mensagem SOAP,

definindo um esquema XML, que possibilita incluir de forma padronizada as informaes relacionadas cifragem dos dados, a assinaturas digitais da mensagem SOAP para construo de WS seguros, fazendo uso das especificaes a XML Digital Signature, a XML Encryption. A seguir, a Figura 5 apresenta uma mensagem SOAP que usa segurana baseada em tokens, assinaturas digitais e criptografia.

20

FIGURA 5 - Mensagem SOAP ilustrando o WS-Security (OASIS, 2004c) A linha (002) indica o incio da mensagem SOAP. A linha (004) indica o incio do cabealho associado com a mensagem SOAP. As linhas (005) a (009) especificam a origem e o destino da mensagem. A linha (010) indica o incio da segurana da especificao do WS-Security. Essas especificaes de segurana esto contidas no cabealho de mensagens SOAP para informar o receptor. As linhas (012) a (014) especificam token de segurana associado com a mensagem. O token est associado com o username do cliente Zoe. As linhas (015) a (033) indicam uma especificao de XML Signature. Essa assinatura assegura a integridade dos elementos assinados, desta forma, os elementos assinados no podero ser modificados indevidamente. A assinatura baseada em uma chave gerada da senha dos usurios, um dos mecanismos mais fortes de serem usados pela especificao. As linhas (016) a (028) descrevem a assinatura digital. A linha (017) especifica o mtodo Canonicalize (para normalizar) os dados que esto sendo assinados. As linhas (021) a (025) indica a seleo dos elementos assinados. Na linha (021), informa que o elemento <S:Body> assinado. Especificamente, indica que o corpo da mensagem ser assinado. A linha (027) especifica o valor da assinatura do formulrio canonizado os dados que esto sendo assinados como definidos na especificao da XML Digital Signature. As linhas (028) a (032) fornecem uma sugesto a respeito de onde encontrar o token associado a segurana com essa assinatura. Especificamente, as linhas (029) a (030) indicam qual token de segurana pode ser encontrado na URL especificada. As linhas (031) a (035) contm o corpo (payload) da mensagem SOAP.

21

Conforme discutido, a Figura 5, apresentou a estrutura do padro WS-Security fazendo uso de algumas especificaes de segurana que sero abordadas nos prximos tpicos deste captulo.

3.2

XML Digital Signature

Segundo (Bartel, 2002): O uso de assinaturas digitais9 um forma de garantir

as propriedades de integridade e autenticidade de informaes digitais.. O XML Digital Signature um padro aberto controlado pela OASIS, proposta conjunta entre W3C e IETF (Internet Engineering Task Force), define regras para gerar e validar assinaturas digitais expressa em XML. O XML Digital Signature um conjunto de tags XML. Essas tags tm a funo de conter informaes suficientes para permitir que um cliente seja verificado usando o par de chaves pblica/privada. O uso do padro XML Digital Signature no est estritamente voltado para assinar documentos XML. Tambm, possvel assinar qualquer tipo de documento eletrnico do tipo de arquivos binrio ou textos, desta forma, a assinatura ser representada atravs de um documento XML. Uma caracterstica fundamental da assinatura em documentos XML a habilidade de assinar somente partes especficas da rvore do documento XML. Dessa forma, permite que outras partes desse documento sofram modificaes sem que isso invalide a parte assinada, permitindo compor assinaturas de modo que diferentes assinaturas sejam aplicadas a diferentes partes do documento. Isso importante porque algumas mensagens SOAP obtm informaes adicionais no seu ciclo de vida. Esta flexibilidade permite garantir a integridade de certas partes de um documento XML. A Figura 6 apresenta um trecho de documento XML que mostra um exemplo de XML Digital Signature:

Conjunto de instrues matemticas baseadas na criptografia, que permite conferir autenticidade, privacidade e inviolabilidade aos documentos digitais e transaes comerciais efetuadas pela Internet.

22

FIGURA 6 Sintaxe do XML Digital Signature (Hendricks, 2002) Segundo Hendricks (2002, p. 193), a informao assinada aparece dentro do elemento <SignedInfo>. O algoritmo usado no clculo do elemento <SignatureValue> mencionado dentro da seo assinada. O elemento <SignatureMethod> especifica o algoritmo usado para converter o SignedInfo canonizado10 no SignatureValue. Esta uma combinao de um algoritmo que depende da chave e de um algoritmo de resumo neste caso, DSA e SHA-1. O elemento <KeyInfo> indica a chave que usada para validar a assinatura. O padro Canonical XML (XML Canonical) (Boyer, 2001) uma especificao que descreve um processo de herana de atributos XML namespace, definindo meios para representar documentos na forma cannica. O interpretador XML expressa que o elemento <Conta> e o elemento <Conta> so equivalentes. Porm, ao criar uma assinatura expressa em XML referentes aos elementos citados, aplica-se um algoritmo gerando duas assinaturas distintas. Assim, documentos XML, que sejam sintaticamente diferentes, porm com lgicas equivalentes, permitem serem representados por uma mesma forma cannica. Isso importante porque, possibilita que os documentos XML possam ser assinados sem que haja preocupao com a sintaxe dos mesmos. Existem trs formas diferentes de representar as assinaturas conforme apresentado na Figura 7: enveloped: a assinatura encontra-se dentro do documento XML que contm os dados, assinando pores ou todo o documento. ideal para ser utilizada com Servios Web, inserida em mensagens SOAP;

10

Algoritmo de verificao de inconsistncia em contedos XML antes de extrair a representao em bits para posterior processamento de uma assinatura.

23

enveloping: a assinatura encapsula os dados assinados, ou seja, contido dentro da prpria estrutura da assinatura. detachedsignature: a assinatura aplicadas aos dados externos ao elemento onde se encontra a assinatura, portanto a assinatura fica separado dos dados assinados. Geralmente estes dados encontram-se na Web. ideal para assinar documentos que sofrem constantes modificaes.

FIGURA 7 - Formas de assinatura XML Digital Signature (Bartel, 2002)

3.3

XML Encryption
O padro XML Encryption (Imamura, 2002) prov segurana fim-a-fim para

aplicaes que necessitam realizar trocas de dados de forma segura. A segurana provida do padro oferece um nvel de privacidade por cifrar os dados evitando que terceiros vejam seu contedo, desta forma, a criptografia em XML fornece funcionalidades complementares para assinatura XML (XML Signature) e permite criptografar um documento XML completo, partes selecionadas de um documento XML ou contedo referenciado por um documento XML. Segundo Potts (2003, p. 296) esclarece: A maneira mais simples, embora mais til, de proteger sua mensagem de Web Services usar o Secure Socket Layer (SSL).. O SSL um protocolo proprietrio da Netscape Communication e o Transport Layer Security (TLS) a definio RFC 2246 do padro da IETF. Os dois protocolos so semelhantes, mas o TLS possui alguns aprimoramentos importantes. Os TLS/SSL so usados com mais frequncia para oferecer proteo e integridade (criptografia) dos dados sobre o protocolo HTTP. Os protocolos TLS/SSL possuem algumas limitaes em um ambiente de Web Services. Esses protocolos, por si s, no podem fornecer autenticao, integridade de 24

dados durante a existncia da mensagem se ela for roteada atravs de mais de um WS. A XML Encryption no pretende substituir TLS/SSL, mas garante confidencialidade persistente, garantindo assim confidencialidade dos dados depois do trmino da sesso. A XML Encryption prov um mecanismo de segurana que no coberto pelo TLS/SSL, como a possibilidade de cifrar somente parte de um dado e o estabelecimento de sesses seguras entre mais de duas partes. Em um ambiente de Web Services, importante que os dados cifrados sejam representados de uma forma estruturada que permitem o uso de diferentes chaves para cifrar parte do documento, desta forma, o 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. A Figura 8 a seguir apresenta, de maneira breve, a estrutura da sintaxe para a criptografia XML. Os pontos de interrogao no cdigo a seguir so substitudos por entradas efetivas:

FIGURA 8 Estrutura da XML Encryption (Hendricks, 2002) Segundo Hendricks (2002), o elemento <EncryptedData> est na primeira parte da sintaxe da criptografia XML que, como o elemento <EncryptedKey>, usada para transportar as chaves de criptografia do originador at um receptor conhecido, e derivada do tipo abstrato <EncryptedType>. Os dados a serem criptografados podem ser qualquer um dos seguintes, resultados em um elemento de criptografia XML que contenha, ou faa referncia, os dados cifrados: dados arbitrrios, o elemento <EncryptedData> pode tornar-se a raiz de um novo documento XML, ou um elemento25

filho; documento XML, o elemento <EncryptedData> pode torna-se a raiz de um novo documento; elemento XML, o elemento <EncryptedData> substitui o elemento ou contedo na verso criptografada do documento XML; contedo do elemento XML; o elemento <EncryptedData> substitui o elemento ou o contedo na verso criptografada do documento XML. A Figura 9 apresenta um exemplo de documento XML sem criptografia dos dados:

FIGURA 9 Documento XML sem criptografia (Hendricks, 2002) O documento XML mostrado acima, refere-se a informaes de uma conta de um sistema bancrio, informando os elementos: Nome, Numero, Saldo e Senha do cliente responsvel. A Figura 10 apresenta um exemplo do documento anterior usando o padro XML Encryption:

FIGURA 10 Documento XML com criptografia (Hendricks, 2002) Ainda na Figura 10, podemos observar que todos os dados exceto o elemento Nome foram criptografados. As informaes extremamente importantes, como os elementos Numero, Saldo e Senha so apresentados de forma criptografadas e colocadas entre as tags<EncryptedData>, preservando a informao confidencial. O WS-Security fornece estrutura para uma segurana completa e flexvel s necessidades individuais. Para tanto, essa tecnologia prope um conjunto de extenses de cabealho SOAP, que, uma vez utilizados, podero conter XML para os padres j

26

analisados anteriormente (XML Signature, XML Encryption), bem como para os padres que surgiro no futuro (Potts 2003).

27

4. SAML
Segundo OASIS (2005) apud Mello (2006) o framework11 Security Assertion Markup Language (SAML):
consiste de um conjunto de especificaes e esquemas XML, que juntos definem uma forma padro para criar, trocar e interpretar asseres de segurana entre entidades de uma aplicao distribuda. No caso, so definidos meios para expressar, em XML, informaes sobre autenticao, autorizao e atributos de um sujeito, porm as especificaes da SAML no definem uma nova tecnologia ou forma para autenticao, mas sim uma tecnologia que visa garantir a interoperabilidade entre os diferentes sistemas de autenticao12.

O propsito tecnolgico SAML dada em (OASIS, 2005c) : definir, melhorar, e manter um framework padro baseado em XML para criao e trocas informaes de autenticao e autorizao. Segundo [Mello 2006]: Uma assero de segurana um conjunto de afirmaes, concedidas por um emissor SAML, sobre determinadas informaes de um principal. So definidos trs tipos de asseres da especificao SAML (Mello, 2006): Autenticao: fornecida pelo emissor SAML aps a declarao de autenticao com sucesso do usurio, que afirma que o emissor foi autenticado por um determinado meio em um determinado momento; Atributo: uma afirmao contm detalhes especficos sobre uma declarao feita pelo emissor, que, assim especifica estar associado ao(s) atributo(s) especfico(s) para determinar o papel que ir desempenhar dentro do sistema; Autorizao: que indica os direitos que um emissor possui sobe um determinado recurso em questo, sendo que esta declarao de asseres afirma que a requisio de acesso pode levar com base as asseres de autenticao e de atributos.

11 12

Conjunto de funcionalidades comuns para um determinado domnio de aplicaes. A especificao da SAML prev o uso de diferentes mecanismos para a autenticao: usurio e senha, Kerberos, Secure Remote Password, certificados TLS/SSL, chave pblica (X.509, SPKI, XKMS), XML Digital Signature e ainda, possibilita o uso de mecanismos no definidos na especificao.

28

Mesmo prevendo o uso de autoridades responsveis pela emisso dessas asseres, o modelo de uso SAML no as menciona. No entanto, as especificaes ditam os protocolos que visam interao com essas autoridades (OASIS, 2005b). A seguir, a Figura 11 apresenta a estrutura das asseres SAML para uma autenticao, atributos e autorizao respectivamente:

FIGURA 11 Assero SAML de autenticao (OASIS, 2005b) Na Figura 11, esta assero comunica que o cliente Ricardo com o endereo de correio eletrnico ricardo@exemplo.com.br foi autenticado com sucesso. A linha (1) informa que se trata de uma assero. As linhas (2) a (7) informam as condies, que definem limites temporais e os destinatrios da assero. As linhas (8) a (11) contm informao adicional, podendo referir outras asseres. As linhas (12) a (19) informam que se trata de uma autenticao, que neste caso foi realizada com um certificado cliente SSL e a verso do SAML usado. Finalizando o documento de autenticao, temos na linha (20) assinatura da entidade emissora da assero, para garantir a autenticidade e integridade das informaes contidas no documento.

29

FIGURA 12 Assero SAML de atributos (OASIS, 2005b) A Figura 12 informa a assero que o cliente ricardo@exemplo.com.br possui uma conta no domnio wsconta, informando tambm que o mesmo cliente possui uma conta do tipo conta investimento mais seu saldo atual. Os atributos qualificam os valores referentes suas aplicaes e so identificados por seu nome de identificao. A linha (1), referente ao elemento-pai, trata-se de uma assero. A linha (2) informa que se trata da assero de atributos. As linhas (3) a (8) especificam ao cliente que se referem os atributos. As linhas (9) e (12) informa o valor do atributo ContaInfo , contendo as informaes da conta do cliente especificado. A linha (13) a (18) informa o valor do atributo SaldoContaInvestimento, informando tambm o saldo atual do tipo de conta referente ao atributo. Concluindo, na linha (20) refere-se a assinatura da entidade emissora da assero. A Figura 13 exemplifica que a assero contida no documento afirma que o cliente ricardo@exemplo.com.brest e autorizado que pode a consultar o a pgina

http://wsconta.com.br/index.jsp

submeter

formulrio

http://wsconta.com.br/registrar.jsp. As afirmaes foram concebidas pelos atributos Decision do elemento AuthorizationDecisionStatement informando Deny para negao, Permit para permisso e Indetreminate para indeterminao.

30

FIGURA 13 Assero SAML de autorizao (OASIS, 2005b) A linha (1), refere-se ao elemento-pai do documento: trata-se de uma assero. A linha (2) a (4) informa os valores temporais da assero. A linha (5) a (25) autorizam a leitura de recursos e a execuo dos dados que so submetidos. Concluindo, a linha (26) contm a assinatura da entidade emissora da assero de autorizao. Portanto, verifica-se que o TLS/SSL tem capacidade de garantir a segurana necessria para chamadas de Web Services simples e nohierrquicas. A SAML por sua vez, sobrepe-se ao TLS/SSL, pois, apresenta em suas funcionalidades um protocolo de gerao de mensagens baseado em SOAP com dados estruturados em XML, desta maneira capacitando uma empresa a dar testemunho dos direitos de identidade, autenticao e atualizao de usurios humanos e de programa (Potts 2003). Vimos que o SAML permite que domnios da web seguros troquem a autenticao de usurio e os dados de autorizao. Quando um provedor de servios usa a SAML, ele pode entrar em contato com um provedor de identidade separado para autenticar usurios que estejam tentando acessar um contedo seguro.

31

5. WS-Policy
A WS-Policy uma linguagem para definir polticas de servios, oferecendo uma gramtica flexvel e extensvel que permite definir como os recursos e restries das normas de segurana podero ser expressos para o ambiente de Web Services.

5.1

Polticas para Web Services

A WSDL, apresentado no captulo 2, fornece um mecanismo para descrever as funcionalidades presente em um Web Service. Isso permite aos provedores de servios descreverem quais so os servios oferecidos, quais as informaes so necessrias para processar as requisies e informando em quais formatos o servio deve enviar os dados para um cliente. A WSDL tem como objetivo a descrio das propriedades funcionais de um servio. No entanto, se faz necessrio, tambm, a descrio dos requisitos no funcionais de um servio. Esses requisitos, dentre outras caractersticas, podem estar relacionados com a segurana em que o servio possa prover ou exigir. Desta forma, pode-se determinar qual servio escolher, relacionado a um servio que apresente uma poltica de privacidade bem definida ou qualquer outro mecanismo de segurana. A criao de uma poltica para anexar informaes necessrias para definir requisitos adicionais (que deve ser cumpridos pelo cliente e pelo prestador do servio para que a interao entre ambos possa acontecer) que tornam necessrio o surgimento de uma tecnologia WS-Policy, com objetivo de prover um modelo de propsito geral para descrio de polticas. As polticas de segurana so representadas atravs de documentos XML, cujo elemento raiz do documento o elemento Policy. Dentro deste elemento, so representadas colees de asseres (ou assertivas), que quando combinadas representam uma coleo vlida 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 (WS-Policy, 2006). A seguir, a Figura 14 apresenta a estrutura simplificada para expressar polticas da especializao WS-Policy:

32

FIGURA 14 Estrutura simplificada para expressar polticas (WS-Policy, 2006) A especificao WS-Policy demasiada abstrata, expressa as capacidades, requisitos e caractersticas gerais de entidades em um WS baseado em XML. Desta forma, mantendo o foco desse trabalho nas normas de segurana em nvel de segurana de mensagem, com nfase na implementao especializada do WS-Policy chamada de WS-SecurityPolicy que est atrelada ao WS-Security.

5.2

WS-SecurityPolicy
A WS-SecurityPolicy uma especializao da WS-Policy para definir polticas

de segurana que descreve como mensagens devem ser protegidas. A poltica pode aplicar-se a mensagens individuais, a operaes ou a toda a extremidade do servio (WS-SecurityPolicy 2005). As asseres (ou seriam assertivas) WS-SecurityPolicy referem-se s funcionalidades de segurana de WS-Security, WS-Trust (IBM, 2005b) e WSSecureConversation (IBM, 2005a). Podem tambm referir segurana no transporte, como HTTP (WS-SecurityPolicy, 2005). A especializao WS-SecurityPolicy prov flexibilidade nas asseres com respeito a tipos de token, algoritmos de criptografia e mecanismos usados, incluindo o uso de segurana de nvel de transporte. Assim, permite que as mensagens requisitadas evoluam ao longo do tempo (WS-SecurityPolicy, 2005). Por exemplo, uma poltica pode especificar que a mensagem seja assinada com uma chave de certificado digital X.509 e outra pode ditar que a autenticao seja feita com a chave de um bilhete Kerberos. A Figura 15 a seguir, apresenta a estrutura da WS-SecurityPolicy de um servio:

33

FIGURA 15 Estrutura da WS-Policy de um servio (WS-SecurityPolicy, 2005) A linha (1) indica que se trata de uma declarao da poltica e que todas as afirmaes nelas contidas tm que ser satisfeita. A linha (2) indica um vnculo de segurana de criptografia simtrica obrigatria. A linha (3) indica um elemento da poltica que contem declaraes que deve ser satisfeita. A linha (4) indica uma declarao de token de segurana. A linha (5) indica mais uma assero que contm declaraes do tipo de token, que deve ser usado para o Protectiontoken. A linha (6) indica que o tokenKerberosV5 APREQ dever ser usado pelas duas partes que compartilham a mensagem com a finalidade de proteo. A linha (10) indica que a assinatura gerada pelas partes necessita ser criptografada. As linhas (14) a (18) indicam qual parte da mensagem deve ser ocultada pela assinatura principal, neste caso o soap:Body indicado na linha (15) e todos os cabealhos SOAP dentro do espao WSaddressing, indicado na linha (16). As linhas (19) a (21) indicam as partes da mensagem devem ser criptografadas, neste caso somente o elemento soap:Body, indicado na linha (20). A Figura 15 apresentada a existncia de duas sees principais na definio da poltica: o vinculo de segurana e a proteo. A seo da poltica que define o vnculo de segurana referente criptografia da segurana (security binding) permitindo conter: criptografia simtrica

(SymmetricBinding), criptografia assimtrica (AsymmetricBinding) e segurana no transporte (TransportBinding). Assim, o uso da criptografia da segurana pode ser

34

utilizado para adicionar tokens de segurana em cada vnculo de segurana, permitindo a transferncia de chave e estrutura dos cabealhos de segurana. Outra seo importante para a definio dos vnculos de segurana a assero SymmetricBinding. Essa assero permite a conexo segura entre o emissor e o receptor com WS-Security, baseado em criptografia simtrica. Os tokens de segurana

adicionados permitem ter combinaes mutuamente exclusivas, tal como: EncryptionToken (cifra) e SignatureToken (assinatura); ProtectionToken (cifra e assinatura em simultneo).

As requisies que compem as mensagens de resposta assumem as mesmas indicaes de segurana definido da mensagem submetida. Uma seo de segurana contm sub-asseres que so um conjunto de afirmaes, concedidas por um emissor, sobre determinadas informaes. Algumas sub-assero disponveis para detalhar a configurao so: Layout (ordenao dos elementos de segurana), IncludeTimestamp (incluir marca temporal na mensagem), EncryptSignature (cifrar assinatura), EncryptBeforeSign (cifrar antes de assinar), AlgorithmSuite (algoritmos criptogrficos a utilizar), ProtectTokens (includos tokens de segurana na assinatura) e

OnlySignEntireHeadersAndBody (assinar apenas corpo e cabealhos que no os de segurana). As asseres AsymmetricBinding e TransportBinding permitem garantir segurana no transporte das mensagens com base no WS-Security. A

AsymmetricBindinggarante atravs em criptografia simtrica entre o emissor e o receptor e a TransportBinding garante a correlao de segurana por meios externos. As asseres de tokens de segurana possuem propriedades que permitem identificar quais so os tokens aceitos e qual o processamento de ser realizado. Desta forma, os tokens assero podem ser: HttpsToken, UsernameToken, X509Token, KerberosToken, SamlToken. Por exemplo, o token X509Token especificar que a mensagem seja assinada com uma chave de certificado digital X.509. Podemos destacar, ainda, o tokenTokenInlusion, que indica como os tokens de segurana devem ser usados. Segue a propriedade de processamento do token:
Never (nunca): o token nunca pode ser transportado em mensagens, podendo apenas ser referenciado;

35

Once (uma vez): o token deve ser transportado uma vez na primeira mensagem, mas depois no mais. Esta opo usada para iniciar sesses seguras; AlwaysToRecipient (sempre para o receptor): o token deve ser enviado sempre que o emissor enviar uma mensagem para o receptor. O mesmo j no deve acontecer na resposta;

Always (sempre): o token deve ser sempre enviado nas mensagens.

Podemos destacar a seo da poltica que tem como objetivo definir a proteo:
Integridade: indica o que deve ser assinado; Confidencialidade: indica o que deve ser cifrado; Elementos obrigatrios: que partes da mensagem tm que existir.

Vimos, ento, neste captulo uma breve introduo sobre polticas para os Web Services foi apresentada a arquitetura e conceitos bsicos do padro WS-Policy. Destacamos a especializao do WS-Policy, a WS-SecurityPolicy. Essa especializao segue alguns propsitos que podemos destacar: informaes suficientes para que participantes possam determinar compatibilidade e interoperabilidade; e informaes necessrias para que uma entidade possa participar em uma troca segura de mensagens SOAP.

36

6. Estudo de Caso
6.1 Apresentao
Este captulo descreve o estudo de caso conduzido com o objetivo de demonstrar a utilizao prtica da especializao WS-Security, WS-Policy e SAML como parte do trabalho desta monografia. O estudo de caso mostra as principais atividades de um sistema bancrio, implementado em um prottipo de aplicao e um WS, com objetivo de utilizar os principais conceitos relacionados segurana de WS nas mensagens SOAP apresentados neste trabalho. Utilizou-se a ferramenta Apache eXtensible Interaction System 2 (Axis 2) para implementar o prottipo, com necessidade de um mecanismo de processamento SOAP para analisar sintaticamente as mensagens recebidas e para chamar os mtodos que a mensagem indica. O Apache Axis 2 um projeto open source da Apache Software Foundation13 e est atualmente na verso 1.6.0. O Axis 2 trata-se de um projeto de andamento desenvolvido pela Apache para proporcionar muitos recursos no presentes na implementao atual do SOAP Apache14. Axis 2 fornece as ferramentas necessrias para trabalharmos com os Web Services de forma fcil e simplificada. A arquitetura do Apache Axis 2 construda sobre o alicerce de um mecanismo SOAP. No diagrama exibido na Figura 16, ilustra a sequncia numerada das etapas para a consumao de servios disponibilizado pelo WS.

FIGURA 16 Arquitetura do Apache Axis 2 (APACHE, 2011)

13 14

http://www.apache.org/ http://ws.apache.org/soap/

37

A arquitetura do Axis 2 pode ser facilmente integrada qualquer aplicao web, independente do container. No tpico de implementao, neste captulo, ser detalhada a arquitetura do Axis 2.

6.2

Arquitetura do Sistema
Este tpico prover uma viso geral da arquitetura do sistema Bancrio. A

arquitetura definida utiliza frameworks e tecnologias para agilizar o processo de desenvolvimento sendo estruturados em camadas para desacoplar o cdigo fonte e facilitar futuras manutenes. A Figura 17 apresenta a estrutura da arquitetura em camadas do sistema: Apresentao: Adobe Flex Comunicao: BlazeDS e WSDL Negcio: Spring Framework Acesso Dados: Hibernate Framework FIGURA 17 Arquitetura em camadas (Potts, 2003) A seguir, sero descritos cada um dos frameworks e tecnologias utilizadas nas camadas da arquitetura do sistema: Adobe Flex uma tecnologia que suporta o desenvolvimento de aplicaes ricas para a Internet, baseadas na plataforma do Flash15, oferecendo ao usurio uma experincia mais robusta que a tecnologia HTML16 e aos desenvolvedores uma construo rpida e facilitada do layout de GUI17. Adobe BlazeDS - O BlazeDS18 um produto OpenSource que corresponde tecnologia Java server-side que d suporte tanto para o Remoting assim como ao Messaging de objetos trocados entre o Java 19 e o Flex20. Conforme apresentado no captulo 2, a WSDL, ser disponibilizada na camada de comunicao, fornecendo as funcionalidades presentes no Web Service. Essas funcionalidades
15 16

http://www.adobe.com/br/flashplatform/ http://www.w3schools.com/html/ 17 http://www.britannica.com/EBchecked/topic/242033/graphical-user-interface-GUI 18 http://opensource.adobe.com/wiki/display/blazeds/BlazeDS 19 http://www.java.com/pt_BR/about/ 20 http://www.adobe.com/br/products/flex.html

38

refletem as interfaces de servios disponibilizadas na camada de negcio. Spring Framework - Esse framework oferece diversos mdulos que podem ser utilizados de acordo com as necessidades do projeto, como mdulos voltados para desenvolvimento Web, inverso de controle e programao orientada a aspectos, desenvolvimento baseada em POJO e integrao com tecnologias de persistncia como Hibernate e controle de transaes. Hibernate Framework - um framework para o mapeamento objeto-relacional escrito na linguagem Java. Sua principal caracterstica a transformao das classes em Java para tabelas de dados. O Hibernate gera as chamadas SQL e libera o desenvolvedor do trabalho manual da converso dos dados resultante, mantendo o programa portvel para quaisquer bancos de dados SQL (WIKIPDIA, 2012).

6.3

Metodologia
O container Apache TomCat foi utilizado como servidor web do prottipo. E foi

instalado em uma mquina com sistema operacional Windows XP. O Web Service e o cliente do prottipo foram implementados atravs das ferramentas Axis 2 e IDE Eclipse21 Galileo utilizando linguagem de programao Java. As polticas de segurana do prottipo foram implementadas conforme as especificaes desejadas e de forma autnoma usando a biblioteca Apache Commons Policy 1.0. A criao de um cliente teve como objetivo realizar as chamadas dos servios e aplicar os mecanismos de segurana: WS-Security, WS-Policy e SAML. Foram criadas definies de polticas tanto do lado do cliente quanto do lado do WS, policyClient.wsse e policyService.wsse, enfatizado a WS-SecurityPolicy que especializa a WS-Policy para polticas de segurana. A poltica definida teve finalidade de expressar os requisitos de segurana de forma declarativa, importando como o servio pode ser invocado com segurana no transporte ou com segurana na mensagem. A configurao dessas polticas de segurana teve por objetivo a segurana em nvel de transmisso de dados ou da mensagem, objetivando atender os requisitos de identificao, autenticao, integridade, privacidade e no-repdio.

21

http://www.eclipse.org/

39

Desta forma, foram implementados os cenrios de estudo: segurana em tokens, assinaturas digitais, criptografia de documentos XML e autorizao.

6.4

Implementao
Inicialmente, a ferramenta Axis 2 gerou um WS a partir da interface

TransacaoService.java do sistema bancrio, gerando o WS chamado Transacao.jws. A interface como o WS gerado possui dos mtodos creditar e debitar em uma conta, passando em ambos dois parmetros: uma string apresentando o nmero da conta e um double apresentando o valor a ser creditado ou debitado. O WS implementado, no arquivo Transacao.jws, recebeu todos os servios propostos pela aplicao. Os mtodos creditar e debitar retornam ao cliente uma mensagem no console de sucesso, de erro ou de exceo. O Cliente do WS, por sua vez, implementou o arquivo WSClient.java, atravs do objeto Call realizada as chamadas aos mtodos da interface do WS, enviando o nmero da conta e o valor em reais a ser creditados ou debitados. Aps a invocao do servio, o cliente recebe uma mensagem de sucesso, confirmando a transao da operao ou uma mensagem de erro ou de exceo, informando que a transao no foi efetuada corretamente. A comunicao entre o cliente e o WS s realizada atravs do acordo entre as definies das polticas de comunicao, atravs do lado do cliente pelo arquivo policyClient.wsse e pelo lado do WS o arquivo policyService.wsse. Ambos definem a segurana desejada da mensagem SOAP do WS em estudo. Atravs dessas polticas de comunicao, a mensagem SOAP monitorada foi composta pelos mecanismos de segurana definidos.

FIGURA 18 Diagrama de Sequncia da Arquitetura Axis 2 (APACHE, 2011)

40

O Quadro a seguir apresenta os passos necessrios ao processamento de uma requisio de entrada para Web Service alvo seguindo a modelo da arquitetura Axis 2 apresentado na Figura 18. Passo 1 - O cliente (WSClient.java) constri uma requisio do SOAP usando um objeto Call, especificamente a URI de destino, os detalhes do servio (como o nome do servio, o nome do mtodo e parmetros de entrada). A seguir, a mensagem SOAP enviada pelo cliente ao n do processamento da mensagem do Axis 2, no receptor de transporte. A mensagem SOAP do cliente, neste ponto, est em um formato especfico quanto ao protocolo e as polticas de seguranas exigidas (policyClient.wsse e policyService.wsse). Passo 2 O receptor de transporte converte a mensagem vinda do cliente em um objeto Message e o inclui em um objeto MessageContext. Ele tambm carrega vrias propriedades como atributos do SOAP (cabealho SOAP) e define a propriedade transportName no MessageContext. Desta forma, a mensagem SOAP enviada ao dispatcher. Passo 3 O dispatcher responsvel pelo caminhamento da requisio ao WS de destino. Passo 4 WS (Transacao.jws) executa o mtodo e retorna a resposta ao dispatcher, Passo 5 que encaminha a resposta ao remetente do transporte. Passo 6 O remetente do transporte, junto com o objeto do contexto do transporte, envia a mensagem SOAP de volta atravs do protocolo de rede ao requisitante. O objeto do contexto do transporte encapsula os detalhes do receptor do transporte, o contexto relacionado ao iniciador da requisio e o destino da resposta/falha da mensagem, os detalhes da sesso e etc.

6.5

Anlise do Estudo de Caso

Esta sesso o apresenta a avaliao efetuada a partir dos resultados do estudo de

caso. Anlise do Estudo de Caso tem como objetivo demonstrar os padres WS-Policy, WS-Security e SAML, destacando suas aplicabilidades atravs de um estudo de caso que visa avaliao destes padres de segurana. O passo inicial foi anlise e modelagem

41

dos dados e informaes de um prottipo. A anlise dos resultados foi feita usando-se as ferramentas SOAP Monitor da Axis 2 e a Wireshark22. A seguir, ser apresentada a parte de maior interesse para o presente trabalho: a implementao de WS para verificar a autenticao e cifragem usando o WS-Security e aplicar algumas polticas atravs do WS-Policy. Desta forma, dividiremos nosso objeto de estudo em cenrios, contendo 3 implementaes diferentes descritas a seguir: O cenrio 1, ilustra a invocao do mtodo UserNameToken (OASIS 2006), da especializao WS-Security, com o gerenciamento de credenciais declarada no cabealho da mensagem SOAP. Este cenrio iniciado quando o cliente (Web Service Client) realiza uma requisio ao servio de segurana de tokens, solicitando um token vlido que ser informado no elemento <wsse:Username>. Em seguida a senha ocultada usando o algoritmo SHA1 no elemento <wsse:Password>. O resumo da senha a concatenao do nonce mais o tempo de criao, a partir do elemento <wsu:Created>, mais a senha. O elemento <wsse:Nonce> um nmero gerado aleatoriamente que adicionado mensagem, possuindo 16 bytes de comprimento e repassado com o valor base64 codificado. O hash da senha criado a partir do momento da criao e do uso nico. O nonce nunca se repete, um servio pode lembrar o nonce para evitar ataques de replay, onde a mesma mensagem enviada uma segunda vez.

<?xmlversion="1.0" encoding="UTF-8" standalone="yes"?> <e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"> <e:Header> <wsse:Security e:mustUnderstand="1"> <wsse:UsernameToken wsu:Id="UsernameToken-1"> <wsse:Username>XTRJGVB</wsse:Username> <wsse:Password Type="...#PasswordDigest"> B3eYI9nXd8LjMNVkst3rgHh3Rw== </wsse:Password> <wsse:Nonce>WScdhft35f4C4ffmQoBE07sAQ==</wsse:Nonce> <wsu:Created>2011-11-16 T01:24:32Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </e:Header> </e:Envelope>

A mensagem SOAP enviada ao WS com as credenciais declarada, que realiza a validao e verificao dos dados. Se os resultados esto de acordo, o WS retorna uma mensagem informando que autenticao foi realizada com sucesso.
22

http://www.wireshark.org/

42

<?xmlversion="1.0" encoding="UTF-8" standalone="yes"?> <e:Envelope xmlns:d="http://www.w3.org/2001/XMLSchema" xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn0="http://idoox.com/interface" xmlns:wn1="http://systinet.com/xsd/SchemaTypes/"> <e:Body> <wn1:string_Response i:type="d:string"> Autenticao Realizada com Sucesso! </wn1:string_Response> </e:Body> </e:Envelope>

O cenrio 1, garantiu em nvel de transporte de segurana os requisitos de Identificao, Autenticao, Privacidade e Integridade de ambos o Token e todo o corpo da mensagem. O cenrio 2 ilustra os mtodos da especificao XML Digital Signature para representao de regras para gerar e validar assinaturas digitais no cabealho da mensagem SOAP. Esses mtodos associam uma chave com dados referenciados a pessoas ou instituio e permitem aplicar ao contedo de elementos do XML internos ou externos a assinatura.
<?xmlversion="1.0" encoding="UTF-8"?> <e:Envelope xmlns:d="http://www.w3.org/2001/XMLSchema" xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn0="http://systinet.com/xsd/SchemaTypes/"> <e:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility" e:mustUnderstand="1"> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EncryptedKey-1"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"> </xenc:EncryptionMethod> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <wsse:SecurityTokenReference> <wsse:KeyIdentifier EncodingType="wsse:Base64Binary" ValueType="wsse:X509v3">T+DYSrzeRop+C64ebI8TuR4TyCQ=</wsse:KeyIdentifi er> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> TX+gl6mTmEmTwp6lFWSHKxtO4lnw0WfZIXwfiEgcp

43

yAVJH+6NcTaZcIFvIZ5v9kGRYOJ949QO5n0 nAqFq8R0dP7D558O0vVS0DNU8H13L2/XDB2BCx1 jpqhyV+KJWWoF1SKEKTQ5NxlUAyIsTot/NSv7 Q7Y78Yj3ulj4iO4QL6I= </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#EncryptedData-1"\> </xenc:ReferenceList> </xenc:EncryptedKey> <wsse:BinarySecurityToken EncodingType="wsse:Base64Binary" ValueType="wsse:X509v3" wsu:Id="SigningSecurityToken-1"> MIIBkzCB/QIGAPxmR9StMA0GCSqGSIb3DQEBB AUAMBIxEDAOBgNVBAMTB0dhYnJpZWwwGhcLMDQ NVBAMTB0dhYnJpZWwwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANU2/MCVaggHUunOtiGgwR CVjyyY6ngRVk0CDq2+bJR6+PAgHYQgLSQgLXix msJ8EILLyo/aR6ssHpWazdEnOP6SUAWH3yxoCb 8x2U/oHL9Pktl+Fb6eRJDxtn0V5N2DmE3C1moS tfJIoSjW0m9wcmwAwVQdUhENgfRebOvoI5bXAg MBAAEwDQYJKoZIhvcNAQEEBQADgYEAxk0BahTR tu76thJruBanenqitegHWOFPfdV5kg6ZVFX4JH hXR5WntYgknt076j+IVeSOl0GZgljBcY9JiJoO JKoVf5lzNG3A8Km5z8oyIxhe2+KmSUtVRIDF4O 3ZRfq7x2NBcifNibGzkmCCsu6xh3FwzVWFUHXt </wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" wsu:Id="Signature-1"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </ds:SignatureMethod> <ds:Reference URI="#Body-Id-eb9af5a0-a397-11d8-aa21-e6c7e9c1aa21"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </ds:DigestMethod> <ds:DigestValue> pX48QWQ17fdvrXwhjTfXSVydlfw= </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> Ik6s4IScU/1eliE9o0qjUvK8KhtK/q0wFGN3D/ Owk3x0uCoBCIlrEwMqk9oN7rCfXbnnwqUoflll eYyymB7s5hgejud1A9savt76udVcw5UZdp3lAS WPnIqMacJJWcI7SV75YR7Emh6uy/Im0QQnJhiR JsqCW9gODxSMRbq4YEM= </ds:SignatureValue>

44

<ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:ReferenceURI="#SigningSecurityToken-1"> </wsse:Reference> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> <wsu:Timestampwsu:Id="Id-TimestampHeader"> <wsu:Created>2007-06-11T22:09:49Z</wsu:Created> <wsu:Expires>2007-06-11T22:14:49Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> </e:Header> <e:Body xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility" wsu:Id="Body-Id-eb9af5a0-a397-11d8-aa21-e6c7e9c1aa21"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EncryptedData-1" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"> </xenc:EncryptionMethod> <xenc:CipherData> <xenc:CipherValue> MmljBzOaITbv4pQ+tHyb7bnALIUyt8LkyZgX La9H9exMu1LvOJuFZuLzPmKFsogaVlw/iLtnVHl/ 7EDesYzA+CngZE2NeYXzURXbO02stTSycXeag nNJsvE8cayC+mpc8yecRTRvmp5rc0/yc6PUiYyD YtSJaz5ZE9MKqfWD1+LO9pGx8CEyvn/qMvSIl ih8+0qnhfkvxSxFDSA0AgKeKeYy0Em6j2A9vcja Yy+5QOd/4tpzVH7ZzqJY7ojzP6VZZXnx5xF/w 1PXpXN87anaPr9tJeSZ/shP5Kz0pmLJHCFOlmPE u33+uAeyVpX0hyLB2FkdvqORR8jVi9RUylWg LNCUYiW/gGWkIG03uouH/yK7Dnfk3ZMHpfPuD0XS j+2qvXTosJ6n3fIIGCXffVVQZUdzrlU6nam glrscg6JO9ws= </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </e:Body> </e:Envelope>

Atravs da analise do cabealho da requisio SOAP, que a parte que nos interessa, nota-se a criao do elemento EncryptedKey que vai definir a chave que ser usada para cifrar os dados. O mtodo usado para cifrar a chave o RSA 1.5. Outro elemento criado foi o KeyInfo que possui vrios informaes sobre a chave, como por exemplo, o tipo do certificado utilizado, que no caso X509v3. O elemento KeyInfo indica a chave a ser usada para validao da assinatura. Aps a especificao das informaes da chave, foi criado outro elemento que o CipherData que contm a chave cifrada. Aps a definio da chave aparece a definio dos dados cifrados que definida dentro do elemento EncryptedData. Dentro desse elemento, definido o 45

mtodo que ser usado para cifrar os dados (EncryptionMethod), que o triple DES em modo cbc. criado um token binrio que vai ser usado na assinatura da mensagem, atravs do elemento BinarySecurityToken. Aps a criao do token iniciada a criao da assinatura em si com o elemento Signature. Dentro do elemento Signature, temos vrias configuraes referentes assinatura, que so: SignatureMethod: especifica o algoritmo usado na assinatura, no caso, RSA-SHA1. DigestMethod: especifica o mtodo usado para criar o resumo criptogrfico, que no caso foi o SHA-1. DigestValue: valor do resumo criptogrfico.

Depois de especificadas as configuraes da assinatura, podemos ver o valor da assinatura que est no elemento SignatureValue. Ainda dentro da assinatura, temos informaes sobre a chave usada, onde, como podemos ver, foi usado o token binrio criado anteriormente. Tambm temos outro elemento, o Timestamp, igualmente importante para a assinatura, pois ele possui a data de criao e de vencimento da assinatura. Desse modo, termina o cabealho da requisio SOAP onde foram criados a chave e a assinatura necessrios para cifrar e assinar o documento XML. Podemos verificar que o corpo da mensagem foi cifrado usando o triple DES em modo cbc. Desse modo, temos tambm o corpo da mensagem cifrado.
<?xmlversion="1.0" encoding="UTF-8"?> <e:Envelope xmlns:d="http://www.w3.org/2001/XMLSchema" xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn0="http://idoox.com/interface" xmlns:wn1="http://systinet.com/xsd/SchemaTypes/"> <e:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility" e:mustUnderstand="1"> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EncryptedKey-1"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"> </xenc:EncryptionMethod>

46

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <wsse:SecurityTokenReference> <wsse:KeyIdentifier EncodingType="wsse:Base64Binary" ValueType="wsse:X509v3">iFdf9f3Uj1O11NxzwG1jfayzXc8=</wsse:KeyIdentifi er> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> d7AJttRKc+uWWm3tON23DdY3dxtFBcBTxN+e/ Tw+BTwybgfgcV77RJjrcYHE87iNRygh4oTzadpJ b4oq6An5/i7hCsHlHluMBX6SxIOao9O0FsL2Ht M/Fn6YsGB5Pm0lzknvOBeH8/0rBl+wRH3p8Ddg 5GNnsi01m/0yy7c+3pY= </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReferenceURI="#EncryptedData-1"> </xenc:DataReference> </xenc:ReferenceList> </xenc:EncryptedKey> <wsse:BinarySecurityTokenEncodingType="wsse:Base64Binary" ValueType="wsse:X509v3" wsu:Id="SigningSecurityToken-1"> MIIBsjCCARsCBgD8ZkeN4DANBgkqhkiG9w0BAQ QFADAhMR8wHQYDVQQDExZXc1NlY3VyaXR5VGVz dGVTZXJ2aWNlMBoXCzA0MDUwODIwMjJaFwswNj A1MDgyMDIyWjAhMR8wHQYDVQQDExZXc1NlY3Vy aXR5VGVzdGVTZXJ2aWNlMIGfMA0GCSqGSIb3DQ EBAQUAA4GNADCBiQKBgQCnjdPYPSguZahnUlj0 lIUpP+tz/O363qKGF7QX8OmE+3y6PnrZJrLzMK bxVZFHK2kPF1BAsvAGhwe+xNdEdy2IwYpskVd3 4IZIhpzoECHPTBkqBf2GQaWTDhZ6neiALklO2Z EW4znImY4QN/2NyfG2o/9mPK8+z0eYBEIOmM00 hwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAEmT3i sCVE6mJrX8fFRBLP2ovM2UCyfe8Mazph0/Z5Uy 4pGeAp1nfzyNIbyjKQ4punRQu7X8j4G6aVSfeI gOYLyQO1fcLos1nORp/8ivC/GVpoizYy1EiK1m r0t6mQLQ91bj7PNsXHveBPMkqNC7++EWp1oKaO WtV7hdLdEUbWFo </wsse:BinarySecurityToken> <ds:Signaturexmlns:ds="http://www.w3.org/2000/09/xmldsig#" wsu:Id="Signature-1"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </ds:SignatureMethod> <ds:Reference URI="#Body-Id-ec9c8720-a397-11d8-8b79-d1d117818b79"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </ds:DigestMethod> <ds:DigestValue> r/Bu9JJZgZ8zlnlfgdxqZ5+rXdQ= </ds:DigestValue>

47

</ds:Reference> </ds:SignedInfo> <ds:SignatureValue> fKSZRp8bIwxYEddKkLoeK+SteAggkWs//gHT Mxw3cU+Lk6E1xIhYUtY0bAF2Hotimw3BznfBpwvu l43guE7MSnxkmIPMh2bHfSJIdCiXduOAxEGN ZmBIUVXRKmoMXfWFJV0JRaCxxZq5CJxS3/QHqhuk nDoY3JNtNjt/taogMkQ= </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:ReferenceURI="#SigningSecurityToken-1"> </wsse:Reference> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </e:Header> <e:Body xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility" wsu:Id="Body-Id-ec9c8720-a397-11d8-8b79-d1d117818b79"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EncryptedData-1" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"> </xenc:EncryptionMethod> <xenc:CipherData> <xenc:CipherValue> xZ5UIXUOx7Zx/gzaobrI3qA3DhV2+NYg5oUSjZ Pe2W1rbame7n8PkMNPys9R8HiI84iMVpsausPo BKMNzO7PwMoYpCusiw0hmKitf5DALt81i1IHH6 Vz956ntqJmKH9QJICV6Sw+w3rhM1orEkvqNIt+ DgWEDPxT+jTBkb5lXlPnchXX6TYfEK02iei0h1 LqWTBZv9lapZndBrWaRP3XPa6iterDZwztnKJV emijSsPPpCvKmryLP1oNYLtGpQH1kkFvVHjX9h 0oyzabYRI2oC7q9eenlkB3esj+YXaWQBgFvJ06 OA1CXn1ci4K6Bv7P4SmSZ+hE2yyDv3SxJCrjrM hlVwv6mH+UUt6hqROsigGCkU3iwI7of1+niXHK vD3NtRCGXyS1Z85iKEdo3SxvScA305/spMRw11 fZgQwOa1yX/OTGoPjUd0OyjB3TPzUoyE/PmlbK umt/+F9zbeGzTix/VbvT52i8JDt75MTYrn7Hlz urlXXbikTlLM+zkAjr </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </e:Body> </e:Envelope>

A resposta da mensagem SOAP do cenrio 2 exibida acima, idntica a requisio que a originou, com a chave e assinatura definidos no cabealho e o corpo da mensagem cifrado. A especificao XML Digital Signature um componente importante na segurana no transporte de dados da mensagem SOAP. Fornece um mecanismo de

48

assinatura digital muito flexvel, mas no suficiente para resolver todos os modelos de ameaas. O cenrio 2, garantiu os requisitos Integridade, No-repdio, Autenticao de mensagem e Autenticao do assinante. O cenrio 3 apresenta a tecnologia SAML baseado no Single Sign-On. A especificao WS-Security especifica assertivas ou tokens de segurana SAML integrada no mecanismo de segurana da mensagem SOAP.
<?xml version="1.0" encoding="UTF-8"?> <S12:Envelope xmlns:S12="..."> <S12:Header> <wsse:Security xmlns:wsse="..." xmlns:wsu="..." xmlns:wsse11="..."> <saml:Assertion xmlns:saml="..." AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2003-04-17T00:46:02Z" Issuer=www.opensaml.org MajorVersion="1" MinorVersion="1"> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="fpagejpkbhmddfodlbmnfhdginimekieckijbeei" Version="2.0" IssueInstant="2006-05-02T08:49:40Z" ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect" ProviderName="localhost" AssertionConsumerServiceURL="https://localhost/transacao"/> </saml:Assertion> <wsse:SecurityTokenReference wsu:Id=STR1 wsse11:TokenType=http://docs.oasis-open.org/wss/oasis-wsssaml-tokenprofile-1.1#SAMLV1.1> <wsse:KeyIdentifier wsu:Id= ValueType=http://docs.oasis-open.org/wss/oasis-wss-samltokenprofile-1.0#SAMLAssertionID> _a75adf55-01d7-40cc-929f-dbd8372ebdfc </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </wsse:Security> </S12:Header> <S12:Body> . . . </S12:Body> </S12:Envelope>

A mensagem SOAP apresentada acima, descreve implementaes capazes de processar referencias de assero SAML que ocorrem em um elemento

<wsse:Security> do cabealho da mensagem SOAP. A aplicao assume um usurio

49

com a conta ricardo@exemplo.com.br est tentando consumir um servio declarado no WS. O elemento <saml:Assertion> define o local, ligao, e consulta que podem ser utilizados para adquirir a afirmao identificada em uma assero SAML. O valor do atributo ID do elemento <samlp:AuthnRequest> enviado para o provedor de identidade do Servio de SSO que inclui autenticao e autorizao.
<?xml version="1.0" encoding="UTF-8"?> <S12:Envelope xmlns:S12="..."> <S12:Header> <wsse:Security xmlns:wsse="..." xmlns:wsu="..." xmlns:wsse11="..."> <saml:Assertion xmlns:saml="..." AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2003-04-17T00:46:02Z" Issuer=www.opensaml.org MajorVersion="1" MinorVersion="1"> <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ID="hedangifkfodeigidaeijpdnfjkfbnegddealebo" IssueInstant="2006-08-17T10:05:29Z" Version="2.0"> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComments" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>sJAWNV9VzT+CghjrHsJSXAY9DRk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>X9Fx4pFSOlI2byrLXBw8azq26xxdqeF7w1UfQtcZ5l7HfXfkq9Tp2w ==</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxeEu0ImbzRM qzVDZkVG9xD7nN1kuFw==</P> <Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q> <G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5Bpsy4pNWMOHCB iNU0NogpsQW5QvnlMpA==</G>

50

<Y>VMoV//Oh7VytBbZVySNmVZevV1bw7vmJwx5hHszeR25bforBFA19nk+3ehg6SgUjWiX n7HsybemjRFs5x4+XFg==</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <Assertion ID="dojnoaponicbieffopfdecilinaepodfimmkpjij" IssueInstant="2003-04-17T00:46:02Z" Version="2.0"> <Issuer>https://www.opensaml.org/IDP </Issuer> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> ricardo@exemplo.com.br</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" /> </Subject> <Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2008-04-17T00:51:02Z"> </Conditions> <AuthnStatement AuthnInstant="2006-08-17T10:05:29Z"> <AuthnContext> <AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion> </samlp:Response> </wsse:Security> </S12:Header> <S12:Body> . . . </S12:Body> </S12:Envelope>

Nesta etapa, apresentada a mensagem SOAP de resposta do SAML indicando que o usurio ricardo@exemplo.com.br est autorizado a acessar o servio. A mensagem de resposta SAML contm os seguintes elementos: RESPONSE_ID: Uma string de 160 bits contendo um conjunto de caracteres gerados aleatoriamente. ISSUE_INSTANT: Timestamp indicando a date e hora em que a resposta SAML foi gerado. ASSERTION_ID: Atributo da afirmao identificada da assero SAML. 51

USERNAME_STRING: O nome do usurio autenticado. NOT_BEFORE: Timestamp de controle para identificar a data e hora anterior a resposta SAML considerada invlida.

NOT_ON_OR_AFTER: Timestamp de controle para identificar a data e hora aps a resposta SAML considerada invlida.

AUTHN_INSTANT: Timestamp indicando a data e hora em que o usurio foi autenticado.

O cenrio 3 apresentou os mecanismo e procedimentos de segurana representada pelas as asseres SAML na mensagem SOAP, juntamente integrada a especificao WS-Security. A criao das asseres SAML integrada a especializao WS-Security permitiu realizar a comunicao de autenticao e autorizao do usurio, e as informaes de atributos. Segurana de mensagens SOAP no introduz novas ameaas alm das identificadas para SAML ou pelo WSS. O cenrio 3 garantiu os requisitos Integridade, Autenticao e Identificao.

52

7. Consideraes Finais
Os WS firmaram-se no cenrio de comunicao como forma de integrao entre organizaes entre organizaes, aplicaes e processos de negcio. O advento do WS quebrou alguns paradigmas de segurana. Existe agora a possibilidade de garantir segurana dentro do prprio, tal faanha possvel com o uso de padro SOAP e como protocolo de transporte HTTP. As tecnologias estudadas e analisadas ofereceram a proteo de mensagens: como proteger o contedo das mensagens dos servios, garantindo a proteo necessria para identificao, autenticao, integridade, privacidade e no-repdio. No estudo de caso, foi usado a ferramenta Apache Axis 2, que implementou a arquitetura do prottipo e facilitou o uso dos principais padres de seguranas abordados ao longo deste trabalho. O prottipo desenvolvido possibilitou demonstrar a aplicao prtica do padro WS-Security,WS-Police e SAML . Permitiu, ainda, a realizao de uma anlise, atravs da execuo e observao das mensagens trocadas entre o WS e o cliente, ambos implementados no estudo de caso deste trabalho. Uma vantagem do WS Security o suporte a vrios tipos de protocolos e tokens. Entretanto, ele no oferece informaes de como deixar esses protocolos seguros. A ferramenta Axis 2 suportou asseres SAML no caso de uso realizado, mas o mdulo de segurana ainda est muito instvel. A documentao pouca e, em geral, de m qualidade. Desta forma, fica uma sugesto para trabalhos futuros. Nenhuma ferramenta atualmente disponvel no mercado permite realizar negociao de polticas de forma integrada. No prottipo, a negociao de polticas foi efetuada para exemplos simples e de forma autnoma. A poltica descrita no caso de uso muito importante, pois possibilita a configurao de segurana utilizada. Desta forma, aumenta o contedo da mensagem consideradamente, tornando-a complexa. Como sugesto para trabalhos futuros, um tema no abordado neste trabalho, mas que, sem dvida, importante ao ponto de ser fonte de inspirao para os mecanismos de segurana expostos nesta pesquisa, a necessidade de estudar os ataques, ameaas e vulnerabilidades atravs das falhas em aplicaes, tratando dos padres de segurana como agente minimizadores de riscos (VIEIRA, 2010).

53

Outra sugesto para trabalhos futuros a anlise da norma de atuao dos padres de segurana, pois sabido que as especializaes destes padres abrem um leque para diferentes interpretaes, e esta divergncia de interpretaes pode ser obstculo para a interoperabilidade. Os Web Services seguem no bom caminho, no que respeita a segurana, os mecanismos analisados suportaram o cenrio mais comum na soluo dos problemas como identificao, autenticao, integridade, privacidade, no-repdio e evoluo das polticas de segurana nas mensagens. As especificaes de segurana para o ambiente dos Web Services esto alcanando maturidade notvel. Permitindo a possibilidade de oferecer ao mercado e aos clientes o fator fundamental da arquitetura de segurana para Web Services. Para oferecer novas aplicaes de Web Services ao mercado e aumentar a segurana de suas atuais aplicaes de Web Services necessrio o uso das recomendaes das normas de implementaes e a padronizao do gerenciamento de polticas, sendo estas uma infraestrutura confivel no ambiente de Web Services seguros.

54

REFERNCIAS
APACHE (2011) Apache Axis2 Architecture Guide. Disponvel em: <http://axis.apache.org/axis2/java/core/docs/Axis2ArchitectureGuide.html> Acesso em: nov. 2011. Bartel, M., Boyer, J., e Fox, B. (2002). XML-Signature Syntax and Processing. W3C. Disponvel em: <http://www.w3.org/TR/xmldsig-core> Acesso em: set. 2011. Boyer, J. (2001). Canonical XML. W3C. <http://www.w3.org/TR/xml-c14n> Acesso em: nov. 2011. Disponvel em:

Gudgin, M. & Nadalin, A., Web Services Secure Conversation Language (WSSecureConversation), Microsoft, IBM, OpenNetwork, Layer 7, Computer Associates, VeriSign, BEA, RSA Security, Ping Identity, Actional, Computer Associates, 2005. Disponvel em: <http://www.ibm.com/developerworks/webservices/ library/specification/ws-secon/> Acesso em: nov. 2011. Gudgin, M. & Nadalin, A., Web Services Trust Language (WS-Trust), Microsoft, IBM, OpenNetwork, Layer 7, Computer Associates, VeriSign, BEA, Oblix, Reactivity, RSA Security, Ping Identity, VeriSign, Actional, 2005. Disponvel em: <http://www.ibm.com/developerworks/library/specification/ws-trust/> Acesso em: nov. 2011. HENDRICKS, Mack et al. Professional Java Web Services. Rio de Janeiro: Alta Books, 2002. Imamura, T., Dillaway, B., e Simon, E. (2002). XML Encryption Syntax and Processing. W3C. Disponvel em: <http://www.w3.org/TR/xmlenc-core> Acesso em: nov. 2011. MELLO, E. R. ; WANGHAM, M. S. ; FRAGA, Joni da Silva ; CAMARGO, E. T. . Segurana em Servios Web. Minicursos do SBSeg 2006. Porto Alegre: Sociedade Brasileira de Computao, 2006, v. , p. 1-48. OASIS (2004a). UDDI Spec Technical Committee Specification Draft. UDDI Version 3.0.2. Disponvel em: <http://uddi.org/pubs/uddi_v3.htm> Acesso em: Nov 2011. OASIS (2004b). Universal Description, Discovery and Integrationv3.0.2 (UDDI). Organization for the Advancement of Structured Information Standards (OASIS). OASIS (2004c). Web Services Security: SOAP Message Security 1.0. OASIS. Disponvel em: <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soapmessage-security-1.0.pdf> Acesso em: nov. 2011. OASIS (2005c). Security Assertion Markup Language (SAML) 2.0 Technical Overview. Organization for the Advancement of Structured Information Standards (OASIS). 55

OASIS (2005b). SAML Executive Overview. Organization for the Advancement of Structured Information Standards (OASIS). OASIS (2006). Web Services Security: UsernameToken Profile 1.1. Disponvel em: <http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf> Acesso em: mar. 2012. POTTS, Stephen Aprenda em 24 Horas Web Services. Rio de Janeiro: Campus, 2003. W3C (2003). SOAP 1.2 W3C Recommendation.W3C. Disponvel em: <http://www.w3.org/TR/soap12> Acesso em: nov. 2011. W3C (2003a). SOAP 1.2 Usage Scenarios.W3C. Disponvel em: <http://www.w3.org/TR/2003/NOTE-xmlp-scenarios-20030730/> Acesso em: nov. 2011. W3C (2004a). Web Services Architecture. W3C Working Group. Disponvel em: <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211> Acesso em: nov. 2011. W3C (2006). Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Working Group. Disponvel em: <http://www.w3.org/TR/wsdl20/> Acesso em: nov. 2011. WIKIPDIA (2012). A Enciclopdia Livre. Wikimedia 2006. Hibernate. Disponvel em: <http://pt.wikipedia.org/wiki/Hibernate>. Acessado em: jan. 2012. WS-Policy (2006). Web Services Policy Framework. WS-SecurityPolicy (2005). Web Services Security PolicyLanguage. VIEIRA, M., State-of-the-art and Research Opportunities (2010). ICWS 2010 / SERVICES 2010. Disponvel em: < http://eden.dei.uc.pt/~mvieira/> Acesso em: marc. 2012.

56

ANEXO A ARQUIVOS FONTES

Arquivo WSCliente.java este arquivo faz parte da aplicao que acessa o WS do estudo de caso, como mostrado abaixo, o arquivo nada mais uma classe java que contem argumentos referentes a interface publica do WS, sendo possvel invocar os mtodos creditar e debitar da interface publica do WS passando os parmetros necessrio para sua execuo.
import import import import import import java.net.URL; javax.xml.rpc.ParameterMode; org.apache.axis2.client.Call; org.apache.axis2.client.Service; org.apache.axis2.encoding.XMLType; org.apache.axis2.utils.Options;

public class WSCliente { publicstaticvoid main(String[] args) throws Exception { //A classe Options um continer para //as entradas na linha de comando. Options options = new Options(args); //Um endpoit o URL dos Web Services String endpointString = "http://localhost:"+ options.getPort() + "/axis/Fachada.jws"; //Os args so os argumentos de linha de comando args = options.getRemainingArgs(); //verifica se o argumento nulo if(args == null){ System.err.println("Argumento nulo"); } //O primeiro arg o nome do mtodo a ser chamado String methodName = args[0]; //Os outros dois args sao os valores a serem // informados nos metdos referentes. String numero = args[1]; double valor = new Double(args[2]); //O objeto Service conter um handler //para o Web service Service service = new Service(); //O objeto Call conter um handler //para uma chamada ao Web service Call callOne = (Call) service.createCall(); URL endpoint = new URL(endpointString); //Informar ao objeto Call que endpoint acessar callOne.setTargetEndpointAddress(endpoint);

57

//Informa ao objeto Call que o mtodo chamar callOne.setOperationName(methodName); //Configurao dos tipos de parametro e tipo de retorno callOne.addParameter("operacao1", XMLType.XSD_STRING, ParameterMode.IN); callOne.addParameter("operacao2", XMLType.XSD_DOUBLE, ParameterMode.IN); callOne.setReturnType(XMLType.XSD_STRING); //Fazendo a chamada com o mtodo invoke() String resp = (String) callOne.invoke(new Object[]{numero, valor}); //Imprimir o resultado no console System.out.println("A mensagem de resposta: " + resp); } }

Arquivo Transacao.jws este arquivo gerado a partir de da Transacao.java, uma inferface java do prottipo do sistema bancrio. A Transacao.jws apresenta a interface do WS que acessada pelo Cliente.java, a URL do WS e toda a descrio na linguagem WSDL do WS.
<wsdl:definitionstargetNamespace="http://localhost:8080/axis/Fachada.j ws"> <!-WSDL created by Apache Axis 2 version: 1.6 Built on Nov02, 2011 (06:55:48 PDT) --> <wsdl:message name="creditarRequest"> <wsdl:part name="in0" type="xsd:string" /> <wsdl:part name="in1" type="xsd:double" /> </wsdl:message> <wsdl:message name="debitarResponse"> </wsdl:message> <wsdl:message name="creditarResponse"> </wsdl:message> <wsdl:message name="debitarRequest"> <wsdl:part name="in0" type="xsd:string" /> <wsdl:part name="in1" type="xsd:double" /> </wsdl:message> <wsdl:portType name="Transacao"> <wsdl:operation name="creditar" parameterOrder="in0 in1"> <wsdl:input message="impl:creditarRequest" name="creditarRequest" /> <wsdl:outputmessage="impl:creditarResponse" name="creditarResponse" /> </wsdl:operation> <wsdl:operation name="debitar" parameterOrder="in0 in1"> <wsdl:input message="impl:debitarRequest" name="debitarRequest" />

58

<wsdl:output message="impl:debitarResponse" name="debitarResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="FachadaSoapBinding" type="impl:Fachada"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="creditar"> <wsdlsoap:operation soapAction="" /> <wsdl:inputname="creditarRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> <wsdl:output name="creditarResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/Transacao.jws" use="encoded" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="debitar"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="debitarRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> <wsdl:output name="debitarResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/Fachada.jws" use="encoded" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="FachadaService"> <wsdl:port binding="impl:FachadaSoapBinding" name="Fachada"> <wsdlsoap:address location="http://localhost:8080/axis/Transacao.jws" /> </wsdl:port> </wsdl:service> </wsdl:definitions>

Arquivo policyService.wsse Seguindo os padres WS-Security e WSSecurityPolicy, este arquivo foi implementado com objetivo de definir o uma poltica de segurana que ser adotado na comunicao entre aplicaes WS e cliente.
<?xmlversion="1.0" ?> <wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <!-- Especifica a segurana da mensagem SOAP de sada do cliente. --> <wsSecurityOut> <!-- Nome e senha do usurio deve acompanhar a mensagem SOAP--> <userNameToken>

59

<userName>Ricardo</userName> <password type="TEXT">123456</password> </userNameToken> <!-- Mensagem SOAP criptografada com a chave pblica do receptor. Somente o receptor com a chave privada poder decriptograr a mensagem. Com isso, garante a confidencialidade da mensagem SOAP --> <encryption> <encryptionKey> <alias>FG</alias> </encryptionKey> </encryption> <!-- Mensagem SOAP assinada digitalmente pelo enviador com a chave privada. Somente com a chave pblica do enviador, validar a assinatura. Com isso, garante a autenticidade da origem da mensagem.--> <signatureKey> <alias>Cliente</alias> <password>VWvw$23Sdf</password> </signatureKey> </wsSecurityOut> <!-- Especifica os elementos de segurana na mensagem SOAP que retorna do servio web--> <wsSecurityIn> <!-- Mensagem SOAP deve acompanhar um username e senha vlidos--> <token tokenType="username" /> <!-- Encripta a mensagem SOAP com a chave pblica de Fachada.jws. O alias e password so usados para acessar a chave privada de Fachada.jws em Keystore, so elementos de decryptionKey--> <encryptionRequired> <decryptionKey> <alias>Cliente</alias> <password>VWvw$23Sdf</password> </decryptionKey> </encryptionRequired> <!-- Na mensagem SOAP da origem, a chave privada deve ser assinada digitalmente. A chave pblica da origem usada pelo destinatrio para validar a assinatura--> <signatureRequired>true</signatureRequired> </wsSecurityIn> <!-- Localizao do arquivo de chaves e certificados digitais usados para criptograr, decriptograr, assinar e validar mensagens--> <keyStore> <keyStoreLocation>RicardoKey.jks</keyStoreLocation> <keyStorePassword>VWvw$23Sdf</keyStorePassword> </keyStore> </wsSecurityPolicy>

60

Arquivo policyClient.wsse - Seguindo os padres WS-Security e WSSecurityPolicy, este arquivo foi implementado com objetivo de definir o uma poltica de segurana que ser adotado na comunicao entre aplicaes cliente e WS.
<?xml version="1.0" ?> <wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <!-- Especifica os elementos de segurana na mensagem SOAP de entrada no servio web--> <wsSecurityIn> <!-- Mensagem SOAP deve acompanhar um username e password vlidos--> <token tokenType="username" /> <!-- Encripta a mensagem SOAP com a chave pblica de Fachada.jws. O alias e password so usados para acessar a chave privada de Fachada.jws em Keystore, so elementos de decryptionKey--> <encryptionRequired> <decryptionKey> <alias>FG</alias> <password>fg2007mono</password> </decryptionKey> </encryptionRequired> <!-- Na mensagem SOAP da origem, a chave privada deve ser assinada digitalmente. A chave pblica da origem usada pelo destinatrio para validar a assinatura--> <signatureRequired>true</signatureRequired> </wsSecurityIn> <!-- Especifica a segurana da mensagem SOAP de sada do servio web. --> <wsSecurityOut> <!-- Nome e senha do usurio deve acompanhar a mensagem SOAP--> <userNameToken> <userName>Ricardo</userName> <password type="TEXT">123456</password> </userNameToken> <!-- Mensagem SOAP criptografada com a chave pblica do receptor. Somente o receptor com a chave privada poder decriptograr a mensagem. Com isso, garante a confidencialidade da mensagem SOAP --> <encryption> <encryptionKey> <alias>cliente</alias> </encryptionKey> </encryption> <!-- Mensagem SOAP assinada digitalmente pelo enviador com a chave privada. Somente com a chave pblica do enviador, validar a assinatura. Com isso, garante a autenticidade da origem da mensagem.-->

61

<signatureKey> <alias>CESAR</alias> <password>cesar2012mono</password> </signatureKey> </wsSecurityOut> <!-- Localizao do arquivo de chaves e certificados digitais usados para criptograr, decriptograr, assinar e validar mensagens--> <keyStore> <keyStoreLocation>ricardokey.jks</keyStoreLocation> <keyStorePassword>VWvw$23Sdf</keyStorePassword> </keyStore> </wsSecurityPolicy>

O arquivo abaixo representa uma mensagem SOAP gerada a partir da definio das polticas de segurana tento do lado do cliente quanto do lado do WS, usando os padres WS-Security. Atravs da ferramenta Axis 2 foi possvel usar o SOAPMonitor para visualizar a mensagem de requisio do WS.
<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <wsse:Security xmlns:wsse="http://docs.oasisopen.org/wss/2004/01/oasis200401-wss-wssecurity-secext-1.0.xsd" SOAP-ENV:mustUnderstand="1"> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:KeyName> CN=MyCompany, OU=Development, O=MyDevTeam, L=Sealand, ST=WA, C=US </dsig:KeyName> </dsig:KeyInfo> <xenc:CipherData> <xenc:CipherValue> NAAAAPstojvmM+RE9OtVaSSSSSQm9Wz6NI7q+XPNfZUc/55/bQM58coFNa d6PtF9voIS06dAwqvPOg9hwSyTsdfgssdfgsdfgsbo73SVz9ITaPCAQ9dn8USkz7 s0oza3NyIlC6VdI mBkGu87dbmLA2AKvfob7s2lnDTxSrc1eg=342eds </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#Id-6F7LceaMAxS3wyRRENVS3dit" />

62

</xenc:ReferenceList> </xenc:EncryptedKey> <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd" ValueType="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary" wsu:Id="Id- KODO_eyXF4HcN77_hWnLtnXC"> MIICRTCCAa6gAwIBAAIEPrBeaTANBgkqhkiG9w0BAQUFADBnMQsw CQYDVQQGEwJVUzELMAkGA1UECBMCTlkxFjAUBgNVBAcTDU5ldyBZb3JrIENpdHkx DDAKBgNVBAoTA2 ZzETMBEGA1UECxMKY2xpZW50MU9yZzEQMA4GA1UEAxMHY2xpZW50MTAeFw0wMzA0MzAyMz M4MTda Fw0wNDA0MjkyMzM4MTdaMGcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJOWTEWMBQG A1UEBxMNTmV3IF lvcmsgQ2l0eTEMMAoGA1UEChMDb3JnMRMwEQYDVQQLEwpjbGllbnQxT3JnMRAwDg YDVQQDEwdjbGll bnQxMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDF/Q/4VGVOb0fdrXELYh1JzKC76e ICnJLrCC h6nBfpKjZUBBiDlLhphB52arGonEUIBHHO9n68N1hoN/uz5j6H5/KmLRdcA1huAI lcNoWmxC61XjCx EDT+agvrg2D6suyzElusWCrvpIEsWEtCcCD0x/MOVcQLK3q9oMg4ihj4ewIDAQAB MA0GCSqGSIb3DQ EBBQUAA4GBAKgcU99Prrz37UgiTp5NTX4oLDPM+HBmETQB9EnQPDPZ829tsHsPym M42Pe2Qk4TNM/+ ZIdbrFRSft64WWHYjr8K8uBR9F7/a1WyJmiNPE3wkiZlM140HjV8l0fAfwR2d+cd B0RvJpwLx/onTx FcnMlCzJfUUp5mFHzebkw19/WD </wsse:BinarySecurityToken> <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:SignedInfo> <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <dsig:Reference URI="#Id-FRvBBqzkzp27T8MlOBAwunHg"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <dsig:DigestValue> kTKQ8N+fLAMnqQFNzDp60alJjLQ= </dsig:DigestValue> </dsig:Reference> </dsig:SignedInfo>

63

<dsig:SignatureValue> E/W8kk2f4s/lBqZYxejRxN9xeiKwE1bE7oqFCJZ9miBUa06mva59h3spg LLMrBQm+FccT/pj7Bf6ZoIfP8j4CCv2zNcyBm8IHaWg7yP+diVZtUczrK9mcuf6R Qsmxtwo1S3HgYCOEATQ3/5AnsJvVp+GWnmjufOkGYf7Ee1xN/s= </dsig:SignatureValue> <dsig:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#IdKODO_eyXF4HcN77_hWnLtnXC" /> </wsse:SecurityTokenReference> </dsig:KeyInfo> </dsig:Signature> wsse:UsernameToken xmlns:wsu="http://docs.oasisopen.org/wss/2004/01/oasis200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-VHr3d0FmPfnDjtLYTDaICdkZ"> <wsse:Username>Ricardo</wsse:Username> <wsse:Password Type="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wssusername-token-profile-1.0#PasswordText"> 123456 </wsse:Password> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis200401wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-FRvBBqzkzp27T8MlOBAwunHg"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="Id-6F7LceaMAxS3wyRRENVS3dit" Type="http://www.w3.org/2001/04/xmlenc#Element"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" /> <xenc:CipherData> <xenc:CipherValue> 6V1NCg8jq7U6tq5JPLYvbfjXi7f3sk64RzT6GCkxNeAcM5uUNMvym0ZMKVey lu1MWLbFA5MN50NkwnOa11olysZPHHnNuei6h6foQ9c24BQVLV8mJWjc0HiMrR80 hJ6TCVtMEE54Np1QmPOF/ydhPA7QTweiFUvbImp1Hwj0OhYwU4jn7BZTywp+yUAVJ8ODhp eaDPeMXrLI/wTFgnBbfmVqlLvLTngft/IHbKP69r8IFrEUr+ZZSdl0BWj8Hr8x09jiFAgk xw73ZbYay57wMFeM94Xj8FTXYwQSgAKSMNiWAWxNKmGBfA38InrybSbgtWWEX4EKFHMs89 0lmudoNwW1JdekDNLuFmE3AVOfWHqXurplKlCaxfynzhL2WixTk7/bAJfa6ayA+7OuRTXg 6V+tAthaDI2AfRxYEmM3lCn46xeDZAV+W3N3RF8TDtvhIdSSU/UXoamQYpJMxh6xGA== </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

64