C.E.S.A.R.

– CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

Segurança em Web Services: Análise de WS-Security, WSPolicy e SAML

RICARDO MARINHO DE MELO

Recife 2012

SEGURANÇA EM WEB SERVICES: ANÁLISE DE WSSECURITY, WS-POLICY E SAML

Monografia apresentada ao programa de Especialização em Engenharia de Software do Centro de Estudos e Sistemas Educacionais do Recife – C.E.S.A.R, como requisito para a obtenção do título de Especialista em Engenharia de Software com ênfase em Segurança da Informação. Orientação: Prof. Vinicius Cardoso Garcia

Recife 2012

1

AGRADECIMENTO
Agradeço, inicialmente, a Deus, pela vida. Agradeço a todos os professores que, de alguma forma, contribuíram para a concretização da minha pós-graduação.

2

“Agradeço todas as dificuldades que enfrentei; não fosse por elas, eu não teria saído do lugar. As facilidades nos impedem de caminhar. Mesmo as críticas nos auxiliam muito”. (Chico Xavier)

3

RESUMO
A presente monografia pretende introduzir ao leitor conceitos sobre os Web Services, contemplando aquisições a respeito dos mecanismos de segurança aplicados, em particular os padrões WS-Policy, WS-Security e SAML destacando suas aplicabilidades através de um estudo de caso que visa avaliar as propriedades de identificação, autenticação, integridade, privacidade e não-repúdio destes padrões de segurança. O estudo de caso demonstra uma utilização prática das especializações WS-Security, WS-Policy e SAML, utilizada a ferramenta Apache Extensible Interaction System 2.

Palavras-chave: Segurança, Internet, Web Services, WS-Policy, WS-Security, SAML.

4

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.

5

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

6

LISTA DE FIGURAS

FIGURA 1 – Relações 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 – Asserção SAML de autenticação (OASIS, 2005b) ............................ 30 FIGURA 12 - Asserção SAML de atributos (OASIS, 2005b) .................................. 31 FIGURA 13 – Asserção SAML de autorização (OASIS, 2005b) ............................. 32 FIGURA 14 – Documento Estrutura simplificada para expressar políticas (WS-Policy, 2006) ...................................................................................................... 34 FIGURA 15 – Estrutura da WS-Policy de um serviço (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 Seqüência da Arquitetura Axis (APACHE, 2011) ....... 39

7

SUMÁRIO
1. INTRODUÇÃO .......................................................................................................9 1.1 MOTIVAÇÃO ........................................................................................................ 10 1.2 JUSTIFICATIVA ................................................................................................... 10 1.3 ÁREA CIENTÍFICA .............................................................................................. 11 1.4 OBJETIVOS ......................................................................................................... 11 1.5 ESTRUTURA DA DISSERTAÇÃO ........................................................................... 11 2. WEB SERVICES ...................................................................................................13 2.1 2.2 2.3 2.4 2.5 2.6 3. ARQUITETURA DOS WEB SERVICES ..................................................................... 13 NORMALIZAÇÃO .................................................................................................. 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 POLÍTICAS PARA WEB SERVICES ......................................................................... 32 5.2 WS-SECURITYPOLICY ......................................................................................... 33

6.

ESTUDO DE CASO ..............................................................................................37 6.1 6.2 6.3 6.4 6.5 APRESENTAÇÃO................................................................................................... 37 ARQUITETURA DO SISTEMA ................................................................................. 38 METODOLOGIA .................................................................................................... 39 IMPLEMENTAÇÃO ................................................................................................ 40 ANÁLISE DO ESTUDO DE CASO ............................................................................ 41

7.

CONSIDERAÇÕES FINAIS ................................................................................53

REFERÊNCIAS ............................................................................................................55 ANEXO A ARQUIVOS FONTES ...............................................................................57

8

1. Introdução
A internet assumiu seu lugar como um importante veículo de comunicação e em pouco tempo tornou-se meio para realização de negócios, por meio de sua capacidade de atendera os mais diversos sistemas computacionais. O êxito deste ambiente tão heterogêneo foi possível devido o uso de protocolos padronizados, capazes de garantir interoperabilidade entre as aplicações, de modo que não importasse qual sistema operacional ou arquitetura de máquina 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 não visavam interoperabilidade como, por exemplo, com os sistemas computacionais de seus clientes (Potts, 2003). A partir dessa necessidade de interação entre diferentes aplicações, surge uma nova caracterização de sistemas distribuídos que possibilita o câmbio de dados e integração de sistemas já existentes: os Web Services. Os Web Services (W3C, 2004a) utilizam padrões neutros como HTTP e XML, permitindo que as diferentes aplicações sejam integradas através de linguagens e protocolos largamente aceitos, garantindo assim interoperabilidade. Organizações como W3C1 e OASIS2 tem por objetivo projetar e publicar especificações, ou padrões, que cumprem a promessa dos Web Services: interoperabilidade entre as barreiras geográficas, de hardware, de sistema operacional, de linguagem de programação e integração de plataformas a baixo custo (Potts, 2003). Contudo, a segurança na transição de dados tornou-se alvo de estudo porque no universo de Web Services que vai além da transmissão de dados, segurança significa mais do que inviolabilidade de informação. A segurança, nesse contexto, caracteriza-se por uma gama de propriedades onde identificação, autenticação, integridade, privacidade e não-repúdio estão inclusas. Para garantir a segurança nos Web Services, algumas tecnologias foram criadas, entre elas, SAML3, WS-Policy4 e WS-Security5, de forma que as suas especificações tornaram-se indispensáveis para a construção 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

9

Neste contexto, com base na importância da segurança nos Web Services (HENDRICKS, 2002), este trabalho tem por objetivo estudar os mecanismos de segurança utilizados como padrão nos Web Services, definindo, analisando, caracterizando e demonstrando a aplicabilidade, através de um estudo de caso, as tecnologias: SAML, WS-Policy e WS-Security.

1.1 Motivação
O crescimento e a complexidade da infraestrutura da Internet e redes corporativas fizeram com que vários modelos e propostas para a comunicação entre aplicações fossem apresentados como opção para ambientes empresariais e sistemas distribuídos. Com toda esta infraestrutura de tecnologia disponível, os Web Services estão se tornando uma nova opção de negócio para as empresas que planejam utilizar a Internet e redes corporativas como meio de compartilhamento de informações. A segurança é um elemento indispensável para a construção e desenvolvimento de uma infraestrutura confiável. No entanto, garantir a segurança dos Web Services representa um desafio devido às limitações dos padrões e à necessidade de dar suporte a uma considerável demanda de serviços (Potts, 2003). Motivado pelas vantagens dos serviços Web e a segurança exigida dos mesmos na construção de aplicações que usam esses serviços delinearam o principal objetivo deste trabalho que é estudar os mecanismos utilizados como padrão de segurança nos serviços Web: WS-Security, SAML e WS-Policy.

1.2

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

segurança para especificação de mecanismos de proteção para que os Web Services possam contemplar os valores necessários à garantia da segurança na sua utilização. Contudo, já existem padrões promissores para segurança, em especial o padrão WSSecurity (OASIS, 2004c), oferecendo mecanismos padrão de segurança necessários para realizar o intercâmbio seguro de mensagens certificadas em um ambiente de Web Services, através de assinaturas digitais e criptografia. O padrão WS-Policy (WSPOLICY, 2006), que provê um modelo de propósito geral para descrever políticas da segurança e por fim o framework SAML (OASIS, 2005c), define uma forma padrão

10

para criar, trocar e interpretar asserções de segurança entre entidades de uma aplicação distribuída. Este trabalho avalia um estudo de caso real com desenvolvimento de um protótipo para análise da tecnologia de serviços seguros propostos pelas normas: WSSecurity, WS-Policy e SAML. A importância mais significativa desse trabalho é o retrato atual da tecnologia de Web Services, com uma análise aprofundada das normas e implementações de segurança propostas.

1.3

Área Científica
A área científica deste trabalho são os sistemas de informação no âmbito da

segurança de sistemas distribuídos.

1.4

Objetivos
Este trabalho tem como principal objetivo realizar a análise das normas e

implementações de segurança para Web Services e dos resultados obtidos no estudo de caso. Estes objetivos foram decomposto nos seguintes objetivos específicos:   Estudo da plataforma tecnológica de Web Services, com ênfase nas normas de segurança em nível de mensagem; Avaliação de um estudo de caso real com desenvolvimento de um protótipo para análise da tecnologia de serviços seguros propostos pelas normas SAML, WSSecurity e WS-Policy.

1.5

Estrutura da Dissertação
A presente dissertação encontra-se organizada em sete capítulos que, de certa

forma, mostram a sequência que foi seguida ao longo deste trabalho, sequência esta que está delimitada pela Introdução (capítulo 1) e Conclusões e Trabalhos Futuros (capítulo 7).    Capítulo 1 – Introdução– motivação, justificativa, área científica, objetivo e estrutura da dissertação; Capítulo 2 – Web Services – levantamento das normas e implementações de referência da plataforma de Web Services; Capítulo 3 – WS-Security– definição das especificações de segurança proposto pelo framework WS-Security; 11

  

Capítulo 4 – SAML– definição das especificações de segurança proposto pelo framework SAML; Capítulo 5 – WS-Policy– definição das especificações de políticas de segurança proposto pelo framework WS-Policy; Capítulo 6 – Estudo de caso– apreciação dos resultados obtidos com o protótipo do estudo de caso no que respeita ao desenvolvimento das tecnologias WS-Security, WS-Policy e SAML;

Capítulo 7 – Conclusões e Trabalhos Futuros – apresentação das conclusões, os trabalhos futuros e os comentários finais.

12

2. Web Services
Um Web Service é uma aplicação de software que possui interface bem definida e descrita em XML (eXtensible Markup Language), classificada como um tipo específico de serviço. Esses serviços são identificados através de um URI (Uniform Resource Identifier ou identificador uniforme de recursos), e chamadas através das RPCs (Remote Procedure Call ou chamadas de procedimento remoto), como acontece em outros serviços distribuídos. O tipo de informação 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 aplicações. As interações com outras aplicações são realizadas pela troca de mensagens XML em um formato SOAP específico, utilizando padrões da Internet. Os Web Services não são a primeira tecnologia a nos permitir isto, mas são diferentes das tecnologias existentes, pelo fato de usarem padrões neutros de plataforma, como HTTP e XML. Atualmente, as vantagens dos Web Services são atrativas para muitas aplicações, oferecendo flexibilidade e interoperabilidade sobre outras tecnologias. Entre essas vantagens, encontra-se a integração própria para business-to-business (B2B). No entanto, essas aplicações precisam de algum nível de segurança necessário para que as mesmas se interconectem de forma confiável. Desta forma, a segurança tem sido considerada um obstáculo na adoção dos Web Services.

2.1

Arquitetura dos Web Services
A gestão da arquitetura dos WS (Web Services) é fornecida pelo modelo teórico

da Service-Oriented Architecture (SOA). Trata-se de um modelo simples que contém três entidades e três operações. A Figura 1 ilustra esse modelo (Potts, 2003).

FIGURA 1 - Relações entre entidades (W3C, 2004a) 13

O Provedor de serviços: é responsável por duas atividades: a primeira é publicar as interfaces dos serviços providos e a segunda é atender as requisições originadas pelos clientes.

O cliente: após a consulta no diretório para registro de serviços e se o serviço foi encontrado, invoca o serviço diretamente requisitando o provedor de serviços.

 O diretório para registro de serviços: é o repositório responsável por informar
ao cliente a descrição dos serviços e a localização das interfaces dos mesmos. As entidades interagem através de três operações fundamentais: publicar, localizar, invocar. Inicialmente, o provedor de serviços publica as interfaces no diretório para registro de serviços, onde ficarão registrados os serviços. Após a publicação, o cliente poderá fazer uma consulta de um determinado serviço, se esse serviço for localizado no diretório para registro de serviços, o cliente poderá invocar o mesmo ao provedor de serviços toda vez que desejar usá-lo.

2.2

Normalização
A normalização 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), organização responsável pela manutenção da normalização da interoperabilidade, abrange uma série de recomendações a serem adotadas para o desenvolvimento de WS. A pilha de protocolos dos Web Services apresentada na Figura 2 abrange normas que suportam a interação das três entidades mencionadas. Algumas dessas mais importantes normas de WS são definidas pelo W3C (W3C, 2004a).

6

http://www.ws-i.org

14

FIGURA 2 - Arquitetura de normas de WS proposta pelo W3C (W3C, 2004a) A seguir, cada um dos padrões XML, SOAP, WSDL e UDDI que compõem a pilha básica de protocolos e tecnologia base dos WS são explicados em detalhes.

2.3

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

flexível, um subconjunto de SGML. Criado em 1996 e formalizado em 1998, se tornou um importante padrão de troca de dados na Web. O padrão 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 especificação XML contém um conjunto de regras de sintaxe para descrição de dados que é definida por uso de Schemas, norma do W3C, que contém regras de validação dos elementos e atributos de um documento XML. Outro componente muito importante são os namespaces, mantido pela W3C. Os namespaces descrevem uma coleção de nomes, identificados por uma referência URI, que são 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 aplicações, permitindo a criação de sistemas que manipulem facilmente informações entre aplicações e validadas de uma maneira mais padronizada.

2.4

SOAP
O protocolo de comunicação SOAP é uma linguagem XML para troca de

mensagens. Baseia-se em normas como o XML Namespace e XML Schema, que permite independência de linguagem e que trabalha com diversos sistemas operacionais e sobre protocolos de aplicação 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 implementações de Web Services. O SOAP é uma das normas mais importantes dos Web Services, definida pelo consórcio W3C (W3C, 2003). A norma SOAP define a estrutura de documentos XML, proporcionando simplicidade e coerência para que uma aplicação envie mensagens XML para outra, garantindo a independência 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 não só proteger os dados mas, além disso, possibilita transmissão da mensagem SOAP por qualquer protocolo de transporte. O envelope é composto por duas partes: o cabeçalho (SOAP Header) e o corpo (SOAP Body) da mensagem.  Cabeçalho SOAP (SOAP Header): é um elemento opcional e o primeiro elemento filho do envelope. O cabeçalho da mensagem SOAP contém informações, divididas em blocos, podendo conter zero ou mais blocos de cabeçalhos. Essas informações ou diretivas são usadas para gerenciar ou prover segurança, tal como asserções de autorização e autenticação entre outros.

 Corpo SOAP (SOAP Body): é um elemento obrigatório e contém a mensagem
propriamente dita chamada carga útil (Payload). O corpo contém os dados de negócio da mensagem ou qualquer tipo de informação XML. No corpo, também pode estar contido o elemento Fault, que tem por objetivo transportar informações sobre erros que possam vir a ocorrer no processamento dessas informações.

2.5

WSDL
A Web Services Description Language (WSDL) (W3C, 2006) é uma gramática

em XML para definir e especificar as interfaces de um WS. Essas interfaces contêm informações do tipo, localização do serviço, o que o serviço pode fazer e como poderá ser chamado, permitindo assim, a interação do serviço. A WSDL é uma linguagem padrão usada para descrever as funcionalidades de um WS, independente de linguagem e plataforma (W3C, 2006). Tem como objetivo descrever os serviços publicados pelos provedores e que, posteriormente, serão acessados pelos clientes. O WSDL é codificado em XML Schema que obedece a uma estrutura fixa para especificar interface de serviço. 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 vínculo 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 são:
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 são definidos. types: define os tipos de dados, utilizando o XML Schema, ao longo do documento e que serão utilizados entre o servidor e o cliente durante a comunicação. Os tipos de dados são definidos dentro deste elemento para que sejam posteriormente utilizados no elemento message.    message: define, de forma abstrata, as mensagens que serão trocadas, contendo os parâmetros de entra e saído do serviço. operation: este elemento representa a interação particular com o serviço, descrevendo as mensagens de entrada, saída e exceções possíveis e permitidas. portType: descreve um conjunto abstrato de operações mapeadas para suporta um ou mais serviços. A cada operação, estão associados um pedido e uma resposta.  binding: este elemento especifica a ligação de cada elementos abstrato, operações, mensagens e tipos de dados, com protocolo de rede que serão utilizados para transportar os elementos até o destino.  port: associa o elemento binding e o endereço de rede para prover assim um endereço único para acessar um serviço.

 service: descreve onde o serviço está disponível ou publicado, associando entre
o elemento binding e o endereço de rede onde o serviço 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 disponíveis na Internet sejam facilmente encontrados, provendo uma interface para utilização do cliente. Trata-se de um protocolo para registrar, publicar e descobrir WS num ambiente distribuído. Os dados e metadados dos WS são registrados e armazenados em diretórios UDDI registry. Associando a cada estrutura de dados um identificador único, chamado UDDI key, cada empresa ou organização, cria suas próprias regras de classificação. A importância de cada empresa possuir sua classificação permite que clientes realizem consultas mais refinadas, escolhendo o serviço que melhor lhe atende. Os diretórios UDDI não armazenam informações relativas à implementação de um WS, como a WSDL do serviço. Este também contém informações relativas à empresa responsável que prover o serviço. A disponibilidade dos serviços dos WS através de UDDI não é obrigatória (OASIS, 2004c). No domínio de informação da UDDI, existem três tipos de informação que podem ser consagrados no registro UDDI:  Páginas Amarelas: aqui, são incluídos dados gerais como a entidade fornecedora ou os serviços oferecidos. Assim, estes dados são classificados como categorias (i.e. país de origem, a indústria, o produto, entre outros). A pesquisa um Web Service, neste contexto, é feita com base nas categorias.  Páginas Brancas: onde, são incluídas informações básicas de contatos que permite pesquisar um WS com base em dados atrelados à entidade fornecedora do WS. Essas informações são constituídas (i.e. nome de um negócio, descrição do negócio, informação de contato, endereço, fax, ou mesmo incluir identificadores de negócios).  Páginas Verdes: contém um conjunto de informações técnicas sobre um WS, desta forma o programador ao ter acesso essas informações poderá desenvolver sua aplicação que utilize ao WS em questão. Neste capítulo, 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 aplicações. Vimos também algumas organizações responsáveis por controlar as principais normas dos Web Services. 19

3. WS-Security
O WS-Security suporta, integra e unifica vários modelos, mecanismos e tecnologias de segurança, oferecendo mecanismos padrão de segurança necessários para realizar o intercâmbio seguro de mensagens certificadas em um ambiente de Web Services. Novas especificações de segurança definem um conjunto de padrões para extensões de cabeçalhos de mensagens SOAP, utilizados para oferecer maior integridade, confidencialidade e autenticidade. Essas especificações de segurança são garantidas através do uso da Assinatura XML (XML Signature), da Criptografia XML (XML Encryption) e da Autenticação e Autorização XML (SAML).

3.1

Arquitetura do WS-Security
A arquitetura do padrão WS-Security é construída sob a mensagem SOAP,

definindo um esquema XML, que possibilita incluir de forma padronizada as informações relacionadas à cifragem dos dados, a assinaturas digitais da mensagem SOAP para construção de WS seguros, fazendo uso das especificações a XML Digital Signature, a XML Encryption. A seguir, a Figura 5 apresenta uma mensagem SOAP que usa segurança baseada em tokens, assinaturas digitais e criptografia.

20

FIGURA 5 - Mensagem SOAP ilustrando o WS-Security (OASIS, 2004c) A linha (002) indica o início da mensagem SOAP. A linha (004) indica o início do cabeçalho associado com a mensagem SOAP. As linhas (005) a (009) especificam a origem e o destino da mensagem. A linha (010) indica o início da segurança da especificação do WS-Security. Essas especificações de segurança estão contidas no cabeçalho de mensagens SOAP para informar o receptor. As linhas (012) a (014) especificam token de segurança associado com a mensagem. O token está associado com o username do cliente “Zoe”. As linhas (015) a (033) indicam uma especificação de XML Signature. Essa assinatura assegura a integridade dos elementos assinados, desta forma, os elementos assinados não poderão ser modificados indevidamente. A assinatura é baseada em uma chave gerada da senha dos usuários, um dos mecanismos mais fortes de serem usados pela especificação. As linhas (016) a (028) descrevem a assinatura digital. A linha (017) especifica o método “Canonicalize” (para normalizar) os dados que estão sendo assinados. As linhas (021) a (025) indica a seleção 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 formulário canonizado os dados que estão sendo assinados como definidos na especificação da XML Digital Signature. As linhas (028) a (032) fornecem uma sugestão a respeito de onde encontrar o token associado a segurança com essa assinatura. Especificamente, as linhas (029) a (030) indicam qual token de segurança pode ser encontrado na URL especificada. As linhas (031) a (035) contêm o corpo (payload) da mensagem SOAP.

21

Conforme discutido, a Figura 5, apresentou a estrutura do padrão WS-Security fazendo uso de algumas especificações de segurança que serão abordadas nos próximos tópicos deste capítulo.

3.2

XML Digital Signature
Segundo (Bartel, 2002): “O uso de assinaturas digitais9 é um forma de garantir

as propriedades de integridade e autenticidade de informações digitais.”. O XML Digital Signature é um padrão 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 têm a função de conter informações suficientes para permitir que um cliente seja verificado usando o par de chaves pública/privada. O uso do padrão XML Digital Signature não está estritamente voltado para assinar documentos XML. Também, é possível assinar qualquer tipo de documento eletrônico do tipo de arquivos binário ou textos, desta forma, a assinatura será representada através de um documento XML. Uma característica fundamental da assinatura em documentos XML é a habilidade de assinar somente partes específicas da árvore do documento XML. Dessa forma, permite que outras partes desse documento sofram modificações 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 obtêm informações 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:

9

Conjunto de instruções matemáticas baseadas na criptografia, que permite conferir autenticidade, privacidade e inviolabilidade aos documentos digitais e transações comerciais efetuadas pela Internet.

22

FIGURA 6 – Sintaxe do XML Digital Signature (Hendricks, 2002) Segundo Hendricks (2002, p. 193), a informação assinada aparece dentro do elemento <SignedInfo>. O algoritmo usado no cálculo do elemento <SignatureValue> é mencionado dentro da seção assinada. O elemento <SignatureMethod> especifica o algoritmo usado para converter o SignedInfo canonizado10 no SignatureValue. Esta é uma combinação 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 padrão Canonical XML (XML Canonical) (Boyer, 2001) é uma especificação que descreve um processo de herança de atributos XML namespace, definindo meios para representar documentos na forma canônica. O interpretador XML expressa que o elemento <Conta> e o elemento <Conta> são equivalentes. Porém, 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, porém com lógicas equivalentes, permitem serem representados por uma mesma forma canônica. Isso é importante porque, possibilita que os documentos XML possam ser assinados sem que haja preocupação com a sintaxe dos mesmos. Existem três formas diferentes de representar as assinaturas conforme apresentado na Figura 7:  enveloped: a assinatura encontra-se dentro do documento XML que contém os dados, assinando porções ou todo o documento. É ideal para ser utilizada com Serviços Web, inserida em mensagens SOAP;

10

Algoritmo de verificação de inconsistência em conteúdos XML antes de extrair a representação em bits para posterior processamento de uma assinatura.

23

 

enveloping: a assinatura encapsula os dados assinados, ou seja, contido dentro da própria 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 modificações.

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

3.3

XML Encryption
O padrão XML Encryption (Imamura, 2002) provê segurança fim-a-fim para

aplicações que necessitam realizar trocas de dados de forma segura. A segurança provida do padrão oferece um nível de privacidade por cifrar os dados evitando que terceiros vejam seu conteúdo, 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 conteúdo 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 proprietário da Netscape Communication e o Transport Layer Security (TLS) é a definição RFC 2246 do padrão da IETF. Os dois protocolos são semelhantes, mas o TLS possui alguns aprimoramentos importantes. Os TLS/SSL são usados com mais frequência para oferecer proteção e integridade (criptografia) dos dados sobre o protocolo HTTP. Os protocolos TLS/SSL possuem algumas limitações em um ambiente de Web Services. Esses protocolos, por si só, não podem fornecer autenticação, integridade de 24

dados durante a existência da mensagem se ela for roteada através de mais de um WS. A XML Encryption não pretende substituir TLS/SSL, mas garante confidencialidade persistente, garantindo assim confidencialidade dos dados depois do término da sessão. A XML Encryption provê um mecanismo de segurança que não é coberto pelo TLS/SSL, como a possibilidade de cifrar somente parte de um dado e o estabelecimento de sessões 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 revelação de informação para partes não autorizadas e garantam o acesso à informação, por partes autorizadas. A Figura 8 a seguir apresenta, de maneira breve, a estrutura da sintaxe para a criptografia XML. Os pontos de interrogação no código a seguir são substituídos 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 faça referência, os dados cifrados: dados arbitrários, 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 conteúdo na versão criptografada do documento XML; conteúdo do elemento XML; o elemento <EncryptedData> substitui o elemento ou o conteúdo na versão 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 informações de uma conta de um sistema bancário, informando os elementos: Nome, Numero, Saldo e Senha do cliente responsável. A Figura 10 apresenta um exemplo do documento anterior usando o padrão 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 informações extremamente importantes, como os elementos Numero, Saldo e Senha são apresentados de forma criptografadas e colocadas entre as tags<EncryptedData>, preservando a informação confidencial. O WS-Security fornece estrutura para uma segurança completa e flexível às necessidades individuais. Para tanto, essa tecnologia propõe um conjunto de extensões de cabeçalho SOAP, que, uma vez utilizados, poderão conter XML para os padrões já

26

analisados anteriormente (XML Signature, XML Encryption), bem como para os padrões que surgirão 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 especificações e esquemas XML, que juntos definem uma forma padrão para criar, trocar e interpretar asserções de segurança entre entidades de uma aplicação distribuída. No caso, são definidos meios para expressar, em XML, informações sobre autenticação, autorização e atributos de um sujeito, porém as especificações da SAML não definem uma nova tecnologia ou forma para autenticação, mas sim uma tecnologia que visa garantir a interoperabilidade entre os diferentes sistemas de autenticação12.”

O propósito tecnológico SAML dada em (OASIS, 2005c) é: “… definir, melhorar, e manter um framework padrão baseado em XML para criação e trocas informações de autenticação e autorização.” Segundo [Mello 2006]: “Uma asserção de segurança é um conjunto de afirmações, concedidas por um emissor SAML, sobre determinadas informações de um principal.” São definidos três tipos de asserções da especificação SAML (Mello, 2006):  Autenticação: fornecida pelo emissor SAML após a declaração de autenticação com sucesso do usuário, que afirma que o emissor foi autenticado por um determinado meio em um determinado momento;  Atributo: uma afirmação contém detalhes específicos sobre uma declaração feita pelo emissor, que, assim especifica estar associado ao(s) atributo(s) específico(s) para determinar o papel que irá desempenhar dentro do sistema;  Autorização: que indica os direitos que um emissor possui sobe um determinado recurso em questão, sendo que esta declaração de asserções afirma que a requisição de acesso pode levar com base as asserções de autenticação e de atributos.

11 12

Conjunto de funcionalidades comuns para um determinado domínio de aplicações. A especificação da SAML prevê o uso de diferentes mecanismos para a autenticação: usuário e senha, Kerberos, Secure Remote Password, certificados TLS/SSL, chave pública (X.509, SPKI, XKMS), XML Digital Signature e ainda, possibilita o uso de mecanismos não definidos na especificação.

28

Mesmo prevendo o uso de autoridades responsáveis pela emissão dessas asserções, o modelo de uso SAML não as menciona. No entanto, as especificações ditam os protocolos que visam à interação com essas autoridades (OASIS, 2005b). A seguir, a Figura 11 apresenta a estrutura das asserções SAML para uma autenticação, atributos e autorização respectivamente:

FIGURA 11 – Asserção SAML de autenticação (OASIS, 2005b) Na Figura 11, esta asserção comunica que o cliente Ricardo com o endereço de correio eletrônico ricardo@exemplo.com.br foi autenticado com sucesso. A linha (1) informa que se trata de uma asserção. As linhas (2) a (7) informam as condições, que definem limites temporais e os destinatários da asserção. As linhas (8) a (11) contém informação adicional, podendo referir outras asserções. As linhas (12) a (19) informam que se trata de uma autenticação, que neste caso foi realizada com um certificado cliente SSL e a versão do SAML usado. Finalizando o documento de autenticação, temos na linha (20) à assinatura da entidade emissora da asserção, para garantir a autenticidade e integridade das informações contidas no documento.

29

FIGURA 12 – Asserção SAML de atributos (OASIS, 2005b) A Figura 12 informa a asserção que o cliente ricardo@exemplo.com.br possui uma conta no domínio wsconta, informando também que o mesmo cliente possui uma conta do tipo conta investimento mais seu saldo atual. Os atributos qualificam os valores referentes à suas aplicações e são identificados por seu nome de identificação. A linha (1), referente ao elemento-pai, trata-se de uma asserção. A linha (2) informa que se trata da asserção 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 informações da conta do cliente especificado. A linha (13) a (18) informa o valor do atributo „SaldoContaInvestimento‟, informando também o saldo atual do tipo de conta referente ao atributo. Concluindo, na linha (20) refere-se a assinatura da entidade emissora da asserção. A Figura 13 exemplifica que a asserção contida no documento afirma que o cliente ricardo@exemplo.com.brestá e autorizado que pode a consultar o a página

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

submeter

formulário

http://wsconta.com.br/registrar.jsp. As afirmações foram concebidas pelos atributos „Decision‟ do elemento „AuthorizationDecisionStatement‟ informando Deny para negação, Permit para permissão e Indetreminate para indeterminação.

30

FIGURA 13 – Asserção SAML de autorização (OASIS, 2005b) A linha (1), refere-se ao elemento-pai do documento: trata-se de uma asserção. A linha (2) a (4) informa os valores temporais da asserção. A linha (5) a (25) autorizam a leitura de recursos e a execução dos dados que são submetidos. Concluindo, a linha (26) contém a assinatura da entidade emissora da asserção de autorização. Portanto, verifica-se que o TLS/SSL tem capacidade de garantir a segurança necessária para chamadas de Web Services simples e não–hierárquicas. A SAML por sua vez, sobrepõe-se ao TLS/SSL, pois, apresenta em suas funcionalidades um protocolo de geração de mensagens baseado em SOAP com dados estruturados em XML, desta maneira capacitando uma empresa a dar testemunho dos direitos de identidade, autenticação e atualização de usuários humanos e de programa (Potts 2003). Vimos que o SAML permite que domínios da web seguros troquem a autenticação de usuário e os dados de autorização. Quando um provedor de serviços usa a SAML, ele pode entrar em contato com um provedor de identidade separado para autenticar usuários que estejam tentando acessar um conteúdo seguro.

31

5. WS-Policy
A WS-Policy é uma linguagem para definir políticas de serviços, oferecendo uma gramática flexível e extensível que permite definir como os recursos e restrições das normas de segurança poderão ser expressos para o ambiente de Web Services.

5.1

Políticas para Web Services

A WSDL, apresentado no capítulo 2, fornece um mecanismo para descrever as funcionalidades presente em um Web Service. Isso permite aos provedores de serviços descreverem quais são os serviços oferecidos, quais as informações são necessárias para processar as requisições e informando em quais formatos o serviço deve enviar os dados para um cliente. A WSDL tem como objetivo a descrição das propriedades funcionais de um serviço. No entanto, se faz necessário, também, a descrição dos requisitos não funcionais de um serviço. Esses requisitos, dentre outras características, podem estar relacionados com a segurança em que o serviço possa prover ou exigir. Desta forma, pode-se determinar qual serviço escolher, relacionado a um serviço que apresente uma política de privacidade bem definida ou qualquer outro mecanismo de segurança. A criação de uma política para anexar informações necessárias para definir requisitos adicionais (que deve ser cumpridos pelo cliente e pelo prestador do serviço para que a interação entre ambos possa acontecer) que tornam necessário o surgimento de uma tecnologia WS-Policy, com objetivo de prover um modelo de propósito geral para descrição de políticas. As políticas de segurança são representadas através de documentos XML, cujo elemento raiz do documento é o elemento Policy. Dentro deste elemento, são representadas coleções de asserções (ou assertivas), que quando combinadas representam uma coleção válida de alternativas de políticas. As asserções são combinadas através de dois tipos de operadores de políticas: ExactlyOne indica que somente uma das asserções contidas na política poderá fazer parte de uma alternativa de política; All permite a combinação de todas as asserções apresentadas como uma alternativa de política (WS-Policy, 2006). A seguir, a Figura 14 apresenta a estrutura simplificada para expressar políticas da especialização WS-Policy:

32

FIGURA 14 – Estrutura simplificada para expressar políticas (WS-Policy, 2006) A especificação WS-Policy é demasiada abstrata, expressa as capacidades, requisitos e características gerais de entidades em um WS baseado em XML. Desta forma, mantendo o foco desse trabalho nas normas de segurança em nível de segurança de mensagem, com ênfase na implementação especializada do WS-Policy chamada de WS-SecurityPolicy que está atrelada ao WS-Security.

5.2

WS-SecurityPolicy
A WS-SecurityPolicy é uma especialização da WS-Policy para definir políticas

de segurança que descreve como mensagens devem ser protegidas. A política pode aplicar-se a mensagens individuais, a operações ou a toda a extremidade do serviço (WS-SecurityPolicy 2005). As asserções (ou seriam assertivas) WS-SecurityPolicy referem-se às funcionalidades de segurança de WS-Security, WS-Trust (IBM, 2005b) e WSSecureConversation (IBM, 2005a). Podem também referir segurança no transporte, como HTTP (WS-SecurityPolicy, 2005). A especialização WS-SecurityPolicy provê flexibilidade nas asserções com respeito a tipos de token, algoritmos de criptografia e mecanismos usados, incluindo o uso de segurança de nível de transporte. Assim, permite que as mensagens requisitadas evoluam ao longo do tempo (WS-SecurityPolicy, 2005). Por exemplo, uma política pode especificar que a mensagem seja assinada com uma chave de certificado digital X.509 e outra pode ditar que a autenticação seja feita com a chave de um bilhete Kerberos. A Figura 15 a seguir, apresenta a estrutura da WS-SecurityPolicy de um serviço:

33

FIGURA 15 – Estrutura da WS-Policy de um serviço (WS-SecurityPolicy, 2005) A linha (1) indica que se trata de uma declaração da política e que todas as afirmações nelas contidas têm que ser satisfeita. A linha (2) indica um vínculo de segurança de criptografia simétrica obrigatória. A linha (3) indica um elemento da política que contem declarações que deve ser satisfeita. A linha (4) indica uma declaração de token de segurança. A linha (5) indica mais uma asserção que contém declarações 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 proteção. 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 cabeçalhos SOAP dentro do espaço 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 existência de duas seções principais na definição da política: o vinculo de segurança e a proteção. A seção da política que define o vínculo de segurança referente à criptografia da segurança (security binding) permitindo conter: criptografia simétrica

(SymmetricBinding), criptografia assimétrica (AsymmetricBinding) e segurança no transporte (TransportBinding). Assim, o uso da criptografia da segurança pode ser

34

utilizado para adicionar tokens de segurança em cada vínculo de segurança, permitindo a transferência de chave e estrutura dos cabeçalhos de segurança. Outra seção importante para a definição dos vínculos de segurança é a asserção SymmetricBinding. Essa asserção permite a conexão segura entre o emissor e o receptor com WS-Security, baseado em criptografia simétrica. Os tokens de segurança

adicionados permitem ter combinações mutuamente exclusivas, tal como:   EncryptionToken (cifra) e SignatureToken (assinatura); ProtectionToken (cifra e assinatura em simultâneo).

As requisições que compõem as mensagens de resposta assumem as mesmas indicações de segurança definido da mensagem submetida. Uma seção de segurança contém sub-asserções que são um conjunto de afirmações, concedidas por um emissor, sobre determinadas informações. Algumas sub-asserção disponíveis para detalhar a configuração são: Layout (ordenação dos elementos de segurança), IncludeTimestamp (incluir marca temporal na mensagem), EncryptSignature (cifrar assinatura), EncryptBeforeSign (cifrar antes de assinar), AlgorithmSuite (algoritmos criptográficos a utilizar), ProtectTokens (incluídos tokens de segurança na assinatura) e

OnlySignEntireHeadersAndBody (assinar apenas corpo e cabeçalhos que não os de segurança). As asserções AsymmetricBinding e TransportBinding permitem garantir segurança no transporte das mensagens com base no WS-Security. A

AsymmetricBindinggarante através em criptografia simétrica entre o emissor e o receptor e a TransportBinding garante a correlação de segurança por meios externos. As asserções de tokens de segurança possuem propriedades que permitem identificar quais são os tokens aceitos e qual o processamento de ser realizado. Desta forma, os tokens asserção 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 segurança 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 não mais. Esta opção é usada para iniciar sessões seguras; AlwaysToRecipient (sempre para o receptor): o token deve ser enviado sempre que o emissor enviar uma mensagem para o receptor. O mesmo já não deve acontecer na resposta;

   

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

Podemos destacar a seção da política que tem como objetivo definir a proteção:
Integridade: indica o que deve ser assinado; Confidencialidade: indica o que deve ser cifrado; Elementos obrigatórios: que partes da mensagem têm que existir.

Vimos, então, neste capítulo uma breve introdução sobre políticas para os Web Services foi apresentada a arquitetura e conceitos básicos do padrão WS-Policy. Destacamos a especialização do WS-Policy, a WS-SecurityPolicy. Essa especialização segue alguns propósitos que podemos destacar: informações suficientes para que participantes possam determinar compatibilidade e interoperabilidade; e informações necessárias para que uma entidade possa participar em uma troca segura de mensagens SOAP.

36

6. Estudo de Caso
6.1 Apresentação
Este capítulo descreve o estudo de caso conduzido com o objetivo de demonstrar a utilização prática da especialização WS-Security, WS-Policy e SAML como parte do trabalho desta monografia. O estudo de caso mostra as principais atividades de um sistema bancário, implementado em um protótipo de aplicação e um WS, com objetivo de utilizar os principais conceitos relacionados à segurança de WS nas mensagens SOAP apresentados neste trabalho. Utilizou-se a ferramenta Apache eXtensible Interaction System 2 (Axis 2) para implementar o protótipo, com necessidade de um mecanismo de processamento SOAP para analisar sintaticamente as mensagens recebidas e para chamar os métodos que a mensagem indica. O Apache Axis 2 é um projeto open source da Apache Software Foundation13 e está atualmente na versão 1.6.0. O Axis 2 trata-se de um projeto de andamento desenvolvido pela Apache para proporcionar muitos recursos não presentes na implementação atual do SOAP Apache14. Axis 2 fornece as ferramentas necessárias para trabalharmos com os Web Services de forma fácil e simplificada. A arquitetura do Apache Axis 2 é construída sobre o alicerce de um mecanismo SOAP. No diagrama exibido na Figura 16, ilustra a sequência numerada das etapas para a consumação de serviços 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 aplicação web, independente do container. No tópico de implementação, neste capítulo, será detalhada a arquitetura do Axis 2.

6.2

Arquitetura do Sistema
Este tópico prover uma visão geral da arquitetura do sistema Bancário. A

arquitetura definida utiliza frameworks e tecnologias para agilizar o processo de desenvolvimento sendo estruturados em camadas para desacoplar o código fonte e facilitar futuras manutenções. A Figura 17 apresenta a estrutura da arquitetura em camadas do sistema: Apresentação: Adobe Flex Comunicação: BlazeDS e WSDL Negócio: Spring Framework Acesso à Dados: Hibernate Framework FIGURA 17 – Arquitetura em camadas (Potts, 2003) A seguir, serão descritos cada um dos frameworks e tecnologias utilizadas nas camadas da arquitetura do sistema:  Adobe Flex – É uma tecnologia que suporta o desenvolvimento de aplicações ricas para a Internet, baseadas na plataforma do Flash15, oferecendo ao usuário uma experiência mais robusta que a tecnologia HTML16 e aos desenvolvedores uma construção rápida 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 capítulo 2, a WSDL, será disponibilizada na camada de comunicação, 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 serviços disponibilizadas na camada de negócio.  Spring Framework - Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, inversão de controle e programação orientada a aspectos, desenvolvimento baseada em POJO e integração com tecnologias de persistência como Hibernate e controle de transações.  Hibernate Framework - É um framework para o mapeamento objeto-relacional escrito na linguagem Java. Sua principal característica é a transformação das classes em Java para tabelas de dados. O Hibernate gera as chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dos dados resultante, mantendo o programa portável para quaisquer bancos de dados SQL (WIKIPÉDIA, 2012).

6.3

Metodologia
O container Apache TomCat foi utilizado como servidor web do protótipo. E foi

instalado em uma máquina com sistema operacional Windows XP. O Web Service e o cliente do protótipo foram implementados através das ferramentas Axis 2 e IDE Eclipse21 Galileo utilizando linguagem de programação Java. As políticas de segurança do protótipo foram implementadas conforme as especificações desejadas e de forma autônoma usando a biblioteca Apache Commons Policy 1.0. A criação de um cliente teve como objetivo realizar as chamadas dos serviços e aplicar os mecanismos de segurança: WS-Security, WS-Policy e SAML. Foram criadas definições de políticas 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 políticas de segurança. A política definida teve finalidade de expressar os requisitos de segurança de forma declarativa, importando como o serviço pode ser invocado com segurança no transporte ou com segurança na mensagem. A configuração dessas políticas de segurança teve por objetivo a segurança em nível de transmissão de dados ou da mensagem, objetivando atender os requisitos de identificação, autenticação, integridade, privacidade e não-repúdio.

21

http://www.eclipse.org/

39

Desta forma, foram implementados os cenários de estudo: segurança em tokens, assinaturas digitais, criptografia de documentos XML e autorização.

6.4

Implementação
Inicialmente, a ferramenta Axis 2 gerou um WS a partir da interface

TransacaoService.java do sistema bancário, gerando o WS chamado Transacao.jws. A interface como o WS gerado possui dos métodos creditar e debitar em uma conta, passando em ambos dois parâmetros: uma string apresentando o número da conta e um double apresentando o valor a ser creditado ou debitado. O WS implementado, no arquivo Transacao.jws, recebeu todos os serviços propostos pela aplicação. Os métodos creditar e debitar retornam ao cliente uma mensagem no console de sucesso, de erro ou de exceção. O Cliente do WS, por sua vez, implementou o arquivo WSClient.java, através do objeto Call realizada as chamadas aos métodos da interface do WS, enviando o número da conta e o valor em reais a ser creditados ou debitados. Após a invocação do serviço, o cliente recebe uma mensagem de sucesso, confirmando a transação da operação ou uma mensagem de erro ou de exceção, informando que a transação não foi efetuada corretamente. A comunicação entre o cliente e o WS só é realizada através do acordo entre as definições das políticas de comunicação, através do lado do cliente pelo arquivo policyClient.wsse e pelo lado do WS o arquivo policyService.wsse. Ambos definem a segurança desejada da mensagem SOAP do WS em estudo. Através dessas políticas de comunicação, a mensagem SOAP monitorada foi composta pelos mecanismos de segurança definidos.

FIGURA 18 – Diagrama de Sequência da Arquitetura Axis 2 (APACHE, 2011)

40

O Quadro a seguir apresenta os passos necessários ao processamento de uma requisição de entrada para Web Service alvo seguindo a modelo da arquitetura Axis 2 apresentado na Figura 18. Passo 1 - O cliente (WSClient.java) constrói uma requisição do SOAP usando um objeto Call, especificamente a URI de destino, os detalhes do serviço (como o nome do serviço, o nome do método e parâmetros 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 específico quanto ao protocolo e as políticas de seguranças 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 também carrega várias propriedades como atributos do SOAP (cabeçalho SOAP) e define a propriedade transportName no MessageContext. Desta forma, a mensagem SOAP é enviada ao dispatcher. Passo 3 – O dispatcher é responsável pelo caminhamento da requisição ao WS de destino. Passo 4 – WS (Transacao.jws) executa o método 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 através 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 requisição e o destino da resposta/falha da mensagem, os detalhes da sessão e etc.

6.5

Análise do Estudo de Caso
Esta sessão o apresenta a avaliação efetuada a partir dos resultados do estudo de

caso. Análise do Estudo de Caso tem como objetivo demonstrar os padrões WS-Policy, WS-Security e SAML, destacando suas aplicabilidades através de um estudo de caso que visa avaliação destes padrões de segurança. O passo inicial foi à análise e modelagem

41

dos dados e informações de um protótipo. A análise 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 implementação de WS para verificar a autenticação e cifragem usando o WS-Security e aplicar algumas políticas através do WS-Policy. Desta forma, dividiremos nosso objeto de estudo em cenários, contendo 3 implementações diferentes descritas a seguir: O cenário 1, ilustra a invocação do método UserNameToken (OASIS 2006), da especialização WS-Security, com o gerenciamento de credenciais declarada no cabeçalho da mensagem SOAP. Este cenário é iniciado quando o cliente (Web Service Client) realiza uma requisição ao serviço de segurança de tokens, solicitando um token válido 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 concatenação do nonce mais o tempo de criação, a partir do elemento <wsu:Created>, mais a senha. O elemento <wsse:Nonce> é um número 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 criação e do uso único. O nonce nunca se repete, um serviço 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 validação e verificação dos dados. Se os resultados estão de acordo, o WS retorna uma mensagem informando que autenticação 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"> Autenticação Realizada com Sucesso! </wn1:string_Response> </e:Body> </e:Envelope>

O cenário 1, garantiu em nível de transporte de segurança os requisitos de Identificação, Autenticação, Privacidade e Integridade de ambos o Token e todo o corpo da mensagem. O cenário 2 ilustra os métodos da especificação XML Digital Signature para representação de regras para gerar e validar assinaturas digitais no cabeçalho da mensagem SOAP. Esses métodos associam uma chave com dados referenciados a pessoas ou instituição e permitem aplicar ao conteúdo 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>

Através da analise do cabeçalho da requisição SOAP, que é a parte que nos interessa, nota-se a criação do elemento EncryptedKey que vai definir a chave que será usada para cifrar os dados. O método usado para cifrar a chave é o RSA 1.5. Outro elemento criado foi o KeyInfo que possui vários informações 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 validação da assinatura. Após a especificação das informações da chave, foi criado outro elemento que é o CipherData que contém a chave cifrada. Após a definição da chave aparece a definição dos dados cifrados que é definida dentro do elemento EncryptedData. Dentro desse elemento, é definido o 45

método que será usado para cifrar os dados (EncryptionMethod), que é o triple DES em modo cbc. É criado um token binário que vai ser usado na assinatura da mensagem, através do elemento BinarySecurityToken. Após a criação do token é iniciada a criação da assinatura em si com o elemento Signature. Dentro do elemento Signature, temos várias configurações referentes à assinatura, que são:    SignatureMethod: especifica o algoritmo usado na assinatura, no caso, RSA-SHA1. DigestMethod: especifica o método usado para criar o resumo criptográfico, que no caso foi o SHA-1. DigestValue: valor do resumo criptográfico.

Depois de especificadas as configurações da assinatura, podemos ver o valor da assinatura que está no elemento SignatureValue. Ainda dentro da assinatura, temos informações sobre a chave usada, onde, como podemos ver, foi usado o token binário criado anteriormente. Também temos outro elemento, o Timestamp, igualmente importante para a assinatura, pois ele possui a data de criação e de vencimento da assinatura. Desse modo, termina o cabeçalho da requisição SOAP onde foram criados a chave e a assinatura necessários 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 também 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 cenário 2 exibida acima, é idêntica a requisição que a originou, com a chave e assinatura definidos no cabeçalho e o corpo da mensagem cifrado. A especificação XML Digital Signature é um componente importante na segurança no transporte de dados da mensagem SOAP. Fornece um mecanismo de

48

assinatura digital muito flexível, mas não é suficiente para resolver todos os modelos de ameaças. O cenário 2, garantiu os requisitos Integridade, Não-repúdio, Autenticação de mensagem e Autenticação do assinante. O cenário 3 apresenta a tecnologia SAML baseado no Single Sign-On. A especificação WS-Security especifica assertivas ou tokens de segurança SAML integrada no mecanismo de segurança 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 implementações capazes de processar referencias de asserção SAML que ocorrem em um elemento

<wsse:Security> do cabeçalho da mensagem SOAP. A aplicação assume um usuário

49

com a conta ricardo@exemplo.com.br está tentando consumir um serviço declarado no WS. O elemento <saml:Assertion> define o local, ligação, e consulta que podem ser utilizados para adquirir a afirmação identificada em uma asserção SAML. O valor do atributo ID do elemento <samlp:AuthnRequest> é enviado para o provedor de identidade do Serviço de SSO que inclui autenticação e autorização.
<?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 usuário ricardo@exemplo.com.br está autorizado a acessar o serviço. A mensagem de resposta SAML contém 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 afirmação identificada da asserção SAML. 51

 

USERNAME_STRING: O nome do usuário autenticado. NOT_BEFORE: Timestamp de controle para identificar a data e hora anterior a resposta SAML é considerada inválida.

NOT_ON_OR_AFTER: Timestamp de controle para identificar a data e hora após a resposta SAML é considerada inválida.

AUTHN_INSTANT: Timestamp indicando a data e hora em que o usuário foi autenticado.

O cenário 3 apresentou os mecanismo e procedimentos de segurança representada pelas as asserções SAML na mensagem SOAP, juntamente integrada a especificação WS-Security. A criação das asserções SAML integrada a especialização WS-Security permitiu realizar a comunicação de autenticação e autorização do usuário, e as informações de atributos. Segurança de mensagens SOAP não introduz novas ameaças além das identificadas para SAML ou pelo WSS. O cenário 3 garantiu os requisitos Integridade, Autenticação e Identificação.

52

7. Considerações Finais
Os WS firmaram-se no cenário de comunicação como forma de integração entre organizações entre organizações, aplicações e processos de negócio. O advento do WS quebrou alguns paradigmas de segurança. Existe agora a possibilidade de garantir segurança dentro do próprio, tal façanha é possível com o uso de padrão SOAP e como protocolo de transporte HTTP. As tecnologias estudadas e analisadas ofereceram a proteção de mensagens: como proteger o conteúdo das mensagens dos serviços, garantindo a proteção necessária para identificação, autenticação, integridade, privacidade e não-repúdio. No estudo de caso, foi usado a ferramenta Apache Axis 2, que implementou a arquitetura do protótipo e facilitou o uso dos principais padrões de seguranças abordados ao longo deste trabalho. O protótipo desenvolvido possibilitou demonstrar a aplicação prática do padrão WS-Security,WS-Police e SAML . Permitiu, ainda, a realização de uma análise, através da execução e observação 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 vários tipos de protocolos e tokens. Entretanto, ele não oferece informações de como deixar esses protocolos seguros. A ferramenta Axis 2 suportou asserções SAML no caso de uso realizado, mas o módulo de segurança ainda está muito instável. A documentação é pouca e, em geral, de má qualidade. Desta forma, fica uma sugestão para trabalhos futuros. Nenhuma ferramenta atualmente disponível no mercado permite realizar negociação de políticas de forma integrada. No protótipo, a negociação de políticas foi efetuada para exemplos simples e de forma autônoma. A política descrita no caso de uso é muito importante, pois possibilita a configuração de segurança utilizada. Desta forma, aumenta o conteúdo da mensagem consideradamente, tornando-a complexa. Como sugestão para trabalhos futuros, um tema não abordado neste trabalho, mas que, sem dúvida, é importante ao ponto de ser fonte de inspiração para os mecanismos de segurança expostos nesta pesquisa, é a necessidade de estudar os ataques, ameaças e vulnerabilidades através das falhas em aplicações, tratando dos padrões de segurança como agente minimizadores de riscos (VIEIRA, 2010).

53

Outra sugestão para trabalhos futuros é a análise da norma de atuação dos padrões de segurança, pois é sabido que as especializações destes padrões abrem um leque para diferentes interpretações, e esta divergência de interpretações pode ser obstáculo para a interoperabilidade. Os Web Services seguem no bom caminho, no que respeita a segurança, os mecanismos analisados suportaram o cenário mais comum na solução dos problemas como identificação, autenticação, integridade, privacidade, não-repúdio e evolução das políticas de segurança nas mensagens. As especificações de segurança para o ambiente dos Web Services estão alcançando maturidade notável. Permitindo a possibilidade de oferecer ao mercado e aos clientes o fator fundamental da arquitetura de segurança para Web Services. Para oferecer novas aplicações de Web Services ao mercado e aumentar a segurança de suas atuais aplicações de Web Services é necessário o uso das recomendações das normas de implementações e a padronização do gerenciamento de políticas, sendo estas uma infraestrutura confiável no ambiente de Web Services seguros.

54

REFERÊNCIAS
APACHE (2011) Apache Axis2 Architecture Guide. Disponível 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. Disponível 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. Disponível 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. Disponível 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. Disponível 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. Disponível 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. . Segurança em Serviços Web. Minicursos do SBSeg 2006. Porto Alegre: Sociedade Brasileira de Computação, 2006, v. , p. 1-48. OASIS (2004a). UDDI Spec Technical Committee Specification Draft. UDDI Version 3.0.2. Disponível 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. Disponível 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. Disponível 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. Disponível em: <http://www.w3.org/TR/soap12> Acesso em: nov. 2011. W3C (2003a). SOAP 1.2 – Usage Scenarios.W3C. Disponível em: <http://www.w3.org/TR/2003/NOTE-xmlp-scenarios-20030730/> Acesso em: nov. 2011. W3C (2004a). Web Services Architecture. W3C Working Group. Disponível 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. Disponível em: <http://www.w3.org/TR/wsdl20/> Acesso em: nov. 2011. WIKIPÉDIA (2012). A Enciclopédia Livre. Wikimedia 2006. Hibernate. Disponível 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. Disponível em: < http://eden.dei.uc.pt/~mvieira/> Acesso em: marc. 2012.

56

ANEXO A ARQUIVOS FONTES
Arquivo WSCliente.java – este arquivo faz parte da aplicação 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 possível invocar os métodos creditar e debitar da interface publica do WS passando os parâmetros necessário para sua execução.
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 contêiner 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 são 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 método a ser chamado String methodName = args[0]; //Os outros dois args sao os valores a serem // informados nos metódos 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 método chamar callOne.setOperationName(methodName); //Configuração 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 método 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 protótipo do sistema bancário. A Transacao.jws apresenta a interface do WS que é acessada pelo Cliente.java, a URL do WS e toda a descrição 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 padrões WS-Security e WSSecurityPolicy, este arquivo foi implementado com objetivo de definir o uma política de segurança que será adotado na comunicação entre aplicações WS e cliente.
<?xmlversion="1.0" ?> <wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <!-- Especifica a segurança da mensagem SOAP de saída do cliente. --> <wsSecurityOut> <!-- Nome e senha do usuário deve acompanhar a mensagem SOAP--> <userNameToken>

59

<userName>Ricardo</userName> <password type="TEXT">123456</password> </userNameToken> <!-- Mensagem SOAP criptografada com a chave pública 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 pública 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 segurança na mensagem SOAP que retorna do serviço web--> <wsSecurityIn> <!-- Mensagem SOAP deve acompanhar um username e senha válidos--> <token tokenType="username" /> <!-- Encripta a mensagem SOAP com a chave pública de Fachada.jws. O alias e password são usados para acessar a chave privada de Fachada.jws em Keystore, são 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 destinatário para validar a assinatura--> <signatureRequired>true</signatureRequired> </wsSecurityIn> <!-- Localização 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 padrões WS-Security e WSSecurityPolicy, este arquivo foi implementado com objetivo de definir o uma política de segurança que será adotado na comunicação entre aplicações 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 segurança na mensagem SOAP de entrada no serviço web--> <wsSecurityIn> <!-- Mensagem SOAP deve acompanhar um username e password válidos--> <token tokenType="username" /> <!-- Encripta a mensagem SOAP com a chave pública de Fachada.jws. O alias e password são usados para acessar a chave privada de Fachada.jws em Keystore, são 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 pública da origem é usada pelo destinatário para validar a assinatura--> <signatureRequired>true</signatureRequired> </wsSecurityIn> <!-- Especifica a segurança da mensagem SOAP de saída do serviço web. --> <wsSecurityOut> <!-- Nome e senha do usuário deve acompanhar a mensagem SOAP--> <userNameToken> <userName>Ricardo</userName> <password type="TEXT">123456</password> </userNameToken> <!-- Mensagem SOAP criptografada com a chave pública 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 pública do enviador, validará a assinatura. Com isso, garante a autenticidade da origem da mensagem.-->

61

<signatureKey> <alias>CESAR</alias> <password>cesar2012mono</password> </signatureKey> </wsSecurityOut> <!-- Localização 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 definição das políticas de segurança tento do lado do cliente quanto do lado do WS, usando os padrões WS-Security. Através da ferramenta Axis 2 foi possível usar o SOAPMonitor para visualizar a mensagem de requisição 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

Sign up to vote on this title
UsefulNot useful