DESENVOLVIMENTO DE UM PROTOTIPO PARA COMPOSIÇ´ … filedavi da silva boger¨ desenvolvimento de um prototipo para composiç´ ao˜ dinamica e segura de serviçosˆ web em sistemas

DAVI DA SILVA BOGER

DESENVOLVIMENTO DE UM PROTOTIPO PARA COMPOSICAODINAMICA E SEGURA DE SERVICOS WEB EM SISTEMAS

ABERTOS

Florianopolis

Fevereiro de 2007

DAVI DA SILVA BOGER

DESENVOLVIMENTO DE UM PROTOTIPO PARA COMPOSICAODINAMICA E SEGURA DE SERVICOS WEB EM SISTEMAS

ABERTOS

Projeto de trabalho de conclusao de cursosubmetido como parte dos requisitos paraa obtencao da aprovacao na disciplinade Introducao ao Projeto em Ciencias daComputacao.

Orientador:

Prof. Dr. Michelle Wangham

Co-orientador:

Prof. Dr. Frank Augusto Siqueira

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CENTRO TECNOLOGICO

DEPARTAMENTO DE INFORMATICA E ESTATISTICA

CURSO DEBACHARELADO EM CI ENCIA DA COMPUTACAO

Florianopolis

Fevereiro de 2007

Proposta Inicial de Trabalho de Conclusao de Curso de Ciencia da Computacao.

Tıtulo: Desenvolvimento de um Prototipo para Composicao Dinamica e Segura

de ServicosWebem Sistemas Abertos

Autor: Davi da Silva Boger

Prof. Dr. Frank Augusto Siqueira (Prof. Responsavel)

LISTA DE FIGURAS

1 Diferentes tipos de ataques (MILANEZ, 2005, apud. (STALLINGS, 2000)) . . .p. 11

2 Interacao entre as entidades da AOS (CAMARGO, 2006, apud (BOOTH et

al., 2004)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 17

3 Arquitetura dos servicosWeb(CAMARGO, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . .p. 17

4 Exemplo de documento XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 18

5 Exemplo de documento XML com definicoes de espacos de nomes. . . . . . . . . . .p. 19

6 Exemplo de mensagem SOAP (MITRA, 2003). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 22

7 Parte abstrata de uma descricao WSDL (BOOTH; LIU, 2006).. . . . . . . . . . . . . . . .p. 23

8 Parte concreta de uma descricao WSDL (BOOTH; LIU, 2006). . . . . . . . . . . . . . . .p. 24

9 Exemplo de polıtica expressa na forma normal definida naWS-Policy(BAJAJ

et al., 2006b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 25

10 Exemplos de anexacao de polıtica a um elemento XML de acordo com a

WS-PolicyAttachment(BAJAJ et al., 2006a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 26

11 Exemplos de anexacao de polıtica a umendpoint(descrito segundo aWS-

Addressing(BOX et al., 2004)) usando o mecanismo de anexacao externa da

WS-PolicyAttachment(BAJAJ et al., 2006a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 26

12 Exemplo de assinatura digital segundo aXML-Signature(BARTEL et al.,

2002). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 30

13 Exemplo de cifra segundoXML Encryption(IMAMURA; DILLAWAY; SI-

MON, 2002). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 31

14 Exemplo de chave cifrada segundo aXML Encryption(IMAMURA; DIL-

LAWAY; SIMON, 2002). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 32

15 Modelo de seguranca daWS-Trust(CAMARGO, 2006, apud (ANDERSON

et al., 2005b)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 34

16 Estrutura de um pedido detokenao STS (ANDERSON et al., 2005b). . . . . . . . .p. 35

17 Estrutura de uma resposta a um pedido detokenao STS (ANDERSON et al.,

2005b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 35

18 Processo de autenticacao por pseudonimos daWS-Federation(CAMARGO,

2006, apud (LOCKHART et al., 2006)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 38

SUMARIO

1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 7

1.1 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 9

2 INTRODUCAO A SEGURANCA COMPUTACIONAL . . . . . . . . . . . . . . . . . . . . . . p. 10

2.1 PROPRIEDADES DE SISTEMAS SEGUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 10

2.2 VULNERABILIDADES, AMEACAS E ATAQUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 11

2.3 POITICAS DE SEGURANCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 12

2.4 MECANISMOS DE SEGURANCA

E CONTROLES CRIPTOGRAFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 12

3 SERVICOSWEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 15

3.1 ARQUITETURA ORIENTADA A SERVICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 16

3.2 O FORMATO XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 17

3.2.1 ESPACOS DE NOMES EM XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 19

3.2.2 XML INFORMATION SET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 20

3.2.3 XML SCHEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 21

3.3 PROTOCOLO DE COMUNICACAO ENTRE SERVICOSWEB- SOAP . . . . . . . . p. 21

3.4 DESCRICAO FUNCIONAL DE SERVICOSWEB- WSDL . . . . . . . . . . . . . . . . . . . . .p. 22

3.5 POLITICAS EM SERVICOSWEB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 24

3.5.1 ANEXOS DE POLITICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 25

3.6 SERVICO DE REGISTRO E DIVULGACAO DE SERVICOSWEB- UDDI . . . . . p. 27

4 SEGURANCA EM SERVICOS WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 29

4.1 ESPECIFICACOES DE SECURANCA PARA XML . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 29

4.1.1 XML-SIGNATURE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 29

4.1.2 XML ENCRYPTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 31

4.2 WS-SECURITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 33

4.3 WS-TRUST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 33

4.4 WS-SECURECONVERSATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 35

4.5 WS-SECURITYPOLICY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 36

4.6 WS-FEDERATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 37

REFERENCIAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .p. 39

7

1 INTRODUCAO

A Internet prove uma poderosa infra-estrutura de comunicacao e, devido a isto, a realizacao

de negocios que usufruem desta cresceu muito nosultimos anos, impulsionando assim a de-

manda por aplicacoes distribuıdas. Diante da necessidade da interacao entre as aplicacoes

distribuıdas de diferentes organizacoes, que geralmente nao foram desenvolvidas para serem

interoperaveis, uma nova caracterizacao de sistemas distribuıdos surgiu possibilitando assim a

troca de informacoes e a integracao com os sistemas legados existentes - os ServicosWeb(BO-

OTH et al., 2004). De acordo com MELLO et al. (2006) e CARMINATI, FERRARI e HUNG

(2005), as principais caracterısticas que os tornam uma tecnologia emergente e promissora para

a realizacao de transacoes comerciais, sao:

• possuem um modelo fracamente acoplado e transparente que garante a interoperabilidade

entre os servicos, sem que estes necessitem ter o conhecimento previo de quais tecnolo-

gias estao presentes em cada lado da comunicacao;

• usam um conjunto de padroes, como o HTTP e o XML, que permite a convergencia

de funcionalidades de negocios dıspares atraves de linguagens e protocolos amplamente

aceitos, resultando em uma reducao significativa nos custos totais de desenvolvimento de

aplicacoes de negocio;

• usam interfaces de servicos que sao auto-descritivas e baseadas no padrao XML;

• tornam mais facil a composicao ou a combinacao de diferentes provedores, visando for-

mar servicos mais complexos e sofisticados.

Com um ponto de vista diferente da programacao orientada a objetos em relacao a modula-

ridade, os Servicos Web representam funcoes de negocio completas e sao usados e reutilizados

em transacoes, nao mais no nıvel de um aplicativo individual ou ate mesmo de uma aplicacao

completa, mas sim no nıvel da empresa, ou ate mesmo atraves de empresas, atravessando assim

diferentes domınios administrativos.

8

Devidoa necessidade de uma rapida adaptacao dos negocios para atender novos consumi-

dores e novas condicoes de mercado, cada vez mais as organizacoes, procuram se unir para

criar processos de negocios, que descrevem servicos complexos, que transpassam os seus limi-

tes organizacionais e que sao providos por diferentes parceiros. A composicao de Servicos Web

e uma ferramenta interessante para empresas que desejam fazer negocios de forma dinamica.

A maioria das linguagens de composicao segue o paradigma workflow, no qual a composicao

e definida como um processo de negocio que determina quais Servicos Web participam da

composicao, quais dados sao transferidos entre as atividades do processo e como acontecem

as interacoes (fluxos de controle) (CHARFI; MEZINI, 2005). Conforme definido por PELTZ

(2003), a orquestracao e a coreografia de Servicos Web sao abordagens baseadas em padroes

abertos para conectar os servicos e criar processos de negocios de alto nıvel. A orquestracao

apresenta um processo de negocio executavel, que pode interagir com servicos internos e ex-

ternosa organizacao, que descreve como os Servicos Web podem interagir em nıvel de men-

sagem e que inclui a logica de negocio e a ordem de execucao das tarefas (atividades). Com

a orquestracao, o processoe sempre controlado por uma das partes do negocio, o que difere

da coreografia quee mais colaborativa e que permite que cada parte envolvida descreva sua

participacao na interacao (PELTZ, 2003).

A WS-BPEL (Web Services Business Process Execution Language), padronizada pela OA-

SIS (WEB. . . , 2005a),e a linguagem mais popular para orquestracao de Servicos Web, com

grande aceitacao na academia e na industria (CHARFI; MEZINI, 2005). Diversas companhias

de software, tais como Oracle, SAP, IBM, HP, entre outras, comprovaram a aceitacao deste

padrao quando integraram motores de orquestracao BPEL dentro de seus produtos. Para es-

pecificar a coreografia de processos de negocios, baseados em servicos Web, a W3C propos a

WS-CDL (Web Services Choreography Description Language) (WEB. . . , 2005b). Apesar dos

esforcos da W3C, ao contrario da linguagem de orquestracao WS-BPEL, esta linguagem ainda

nao se tornou um padrao de fato.

No entanto, apesar da sua tendencia para trabalhos colaborativos, muitas organizacoes e/ou

profissionais ainda tem receios em compartilhar informacoes sensıveis, quando ha a neces-

sidade de colaboracao com parceiros desconhecidos (WANGHAM et al., 2005). Para que a

composicao seja segura para todas as partes envolvidas, as organizacoes devem ter polıticas de

seguranca associadas aos recursos de que dispoem, e a colaboracao dinamica pode exigir que

haja um acordo entre as polıticas de seguranca dos diversos domınios administrativos atraves-

sados durante a execucao do processo de negocio.

9

A seguranca basica em Servicos Web - nas trocas de mensagens, autenticacao, definicao

de polıticas de autorizacao, etc. - ja vem sendo bastante estudada e padronizada, entretanto,

quando se consideram as composicoes de servicos, constata-se que a seguranca dos processos de

negocios nao foi ainda profundamente investigada e que ainda nao existem solucoes concretas

e completas (CHARFI; MEZINI, 2005; CARMINATI; FERRARI; HUNG, 2005).

A secao a seguir aborda os objetivos deste trabalho. O restante do texto traz uma revisao

bibliografica dos principais conceitos de seguranca (capıtulo 2), dos padroes basicos de Servicos

Web(capıtulo 3) e dos principais padroes de seguranca para ServicosWeb(capıtulo 4).

1.1 OBJETIVOS

O objetivo geral deste trabalhoe desenvolver um prototipo que facilite a composicao dinamica

de Servicos Web, tendo em vista os aspectos de seguranca envolvidos, e ainda, que leve em

consideracao parametros de qualidade relacionadosa aplicabilidade,a simplicidade ea exten-

sibilidade.

Para alcancar o objetivo geral deste projeto, os seguintes objetivos especıficos foram defi-

nidos:

• realizar um estudo bibliografico dos modelos, conceitos e especificacoes propostos na

literatura que tratam da composicao de Servicos Web;

• modelar e implementar o prototipo com suporte a composicao dinamica de Servicos Web

que integre requisitos de seguranca;

• promover o acordo e composicao dinamica da polıtica de seguranca que sera adota no

processo de negocio;

• submeter o prototipo resultante a uma bateria de testes de software de forma a atestar a

qualidade do mesmo e a sua conformidade com os padroes citados.

• desenvolver um processo de negocios para verificar a aplicabilidade do prototipo imple-

mentado;

• escrever pelo menos um artigo visando divulgar os resultados da pesquisa realizada.

10

2 INTRODUCAO A SEGURANCA COMPUTACIONAL

Este capıtulo apresenta os principais conceitos de seguranca necessarios para o entendi-

mento do restante do texto. Leitores familiarizados com esses conceitos podem pular a leitura

deste capıtulo.

Os principais conceitos de seguranca sao relacionadosas propriedades que um sistema deve

satisfazer para ser considerado seguro. Esses conceitos sao abordados na secao 2.1. Outros

conceitos basicos dizem respeitoa suscetibilidade do sistemaa violacao das propriedades de

seguranca, e sao vistos na secao 2.2. Na secao 2.3e introduzido o conceito de polıtica de

seguranca. Na secao 2.4 sao introduzidos o conceito de mecanismo de seguranca e os controles

criptograficos.

2.1 PROPRIEDADES DE SISTEMAS SEGUROS

Nao existe uma definicao simples e amplamente aceita para seguranca computacional. Nor-

malmente, o que se faze enumerar quais propriedades um sistema deve satisfazer para que possa

ser considerado seguro. As propriedades de sistemas seguros sao, segundo Landwehr (2001):

• Confidencialidade: assegura que as informacoes nao serao reveladas a quem nao tiver

autorizacao;

• Integridade: assegura que as informacoes nao serao alteradas por alguem nao autorizado;

• Disponibilidade: assegura que as informacoes estarao sempre disponıveis a quem for

devidamente autorizado;

• Autenticidade: assegura que algueme realmente quem diz ser;

• Nao Repudio: assegura que alguem nao possa negar autoria de alguma informacao que

efetivamente tenha gerado.

11

Figura 1: Diferentes tipos de ataques (MILANEZ, 2005, apud. (STALLINGS, 2000))

E muito difıcil encontrar sistemas que garantam todas essas propriedades. Isso se da pelo

fato de algumas dessas propriedades dificultarem o compartilhamento de informacoes. Em

ambientes de larga escala, onde ocorre o compartilhamento a diversas partes, aumenta-se a

possibilidade de ocorrerem violacoes de seguranca.

2.2 VULNERABILIDADES, AMEACAS E ATAQUES

Quando um sistema nao garante alguma das propriedades de seguranca, diz-se que ele

apresenta umavulnerabilidade. Essa vulnerabilidadee um ponto fraco do sistema, e permite

que alguem possa violar alguma propriedade de seguranca. Quando ocorre uma circunstancia

que forneca algum potencial de violacao de seguranca, diz-se que o sistema esta sobameaca.

Se a ameaca for efetivada por um usuario mal-intencionado, ocorre oataque. O ataque viola

alguma propriedade de seguranca.

A figura 1 ilustra os tipos basicos de ataques. Um ataque deinterrupc ao e aquele onde

o atacante impede a informacao de chegar ao destinatario. Nesse ataque a propriedades de

disponibilidadee violada. Em um ataque deinterceptacao, o atacante acessa informacoes que

nao tem direito de acessar. Nesse caso, apenas a confidencialidadee violada, porem o atacante

pode se manter oculto por um bom tempo, podendo causar um grande estrago. Namodificacao,

12

o atacante altera o conteudo da mensagem a fim de obter benefıcio ilıcito. Nesse tipo de ataque

a integridadee violada. Napersonificacao, o atacante emite uma mensagem — seja uma

mensagem nova forjada pelo atacante (fabricacao), seja uma mensagem enviada anteriormente

e interceptada pelo atacante (repeticao) — como se fosse outra entidade, violando a propriedade

de autenticidade.

Esses sao os casos mais simples de ataques, e eles podem ser combinados de forma bastante

complexa e engenhosa para driblar os mecanismos de seguranca presentes nos sistemas.

2.3 POITICAS DE SEGURANCA

Landwehr (2001, p. 4) define polıtica de seguranca como sendo um conjunto de regras

para se proteger um computador ou as informacoes contidas nele. Ele tambem compara uma

polıtica de seguranca com as leis da sociedade, no sentido de que em um computador sem uma

polıtica de seguranca, nenhum ato pode ser considerado uma violacao. De forma geral, uma

polıtica e um conjunto de regras que especifica como um sistema deve prover os seus servicos,

limita as operacoes dos usuarios e determina como as informacoes e os recursos devem ser

administrados, protegidos e distribuıdos no interior de um sistema especıfico (ISO/IEC, 2005).

Em Ligatti, Bauer e Walker (2004, p. 3) ha uma definicao bastante simples de polıtica

de seguranca. Uma polıtica de segurancae um predicado sobre uma sequencia de acoes, uma

funcao que diz quando um programa viola alguma regra de seguranca. Forcar o cumprimento

da polıtica significa permitir que programas que satisfacam a polıtica de seguranca possam ser

executados normalmente no sistema, e bloquear ou modificar as acoes dos programas que forem

violar as regras da polıtica. Os meios de forcar o cumprimento de uma polıtica sao chamados

mecanismos de seguranca.

2.4 MECANISMOS DE SEGURANCAE CONTROLES CRIPTOGRAFICOS

Segundo Sandhu e Samarati (1994, p. 41), os mecanismos de seguranca sao os responsaveis

efetivos pelo cumprimento das polıticas de seguranca. Os principais mecanismos de seguranca

realizam autenticacao e controle de acesso (ou autorizacao), se utilizando dehardwaree soft-

warede baixo nıvel (sistema operacional, por exemplo) e criptografia para implementar esses

servicos.

Um mecanismo de autenticacao bastante utilizado para autenticar pessoase o metodo de

13

login e senha. Por meio de uma senha que apenas o usuario e o sistema conhecem, o sistema

e capaz de garantir que a pessoa que esta acessando o sistemae quem ela diz ser. A partir daı

o sistema pode controlar o acesso da pessoa aos recursos do sistema. No entanto, esse metodo

esta sujeitoa dificuldade dos seres humanos em memorizar senhas difıceis de adivinhar.

A criptografiae o meio mais poderoso da atualidade para implementar os mecanismos de

seguranca, e por issoe o mais usado. Umsistema criptografico e constituıdo de um processo

de cifragem, por meio do qual a informacao e ocultada, e um processo dedecifragem, que

desfaz a cifragem trazendo a informacao original. Tanto o processo de cifragem como o de

decifragem sao baseados no uso de segredos, chamadoschaves criptograficas. Ha dois tipos

basicos de sistemas criptograficos:simetrico eassimetrico.

Na criptografia simetrica, a chave usada na cifragem pode ser facilmente calculada a partir

da chave usada na decifragem, e vice-versa. Assim, cada par de entidades que desejam se comu-

nicar devem adotar uma chave, e mante-la em segredo para evitar que o conteudo das mensagens

seja descoberto por uma terceira entidade nao autorizada. Nesse sistema, se as chaves forem

devidamente escondidas, cada parte envolvida na comunicacao sabe quando uma mensageme

autentica, pois somente a chave escolhida poderia ter gerado a cifra. No entanto, uma parte

nao consegue comprovar para um terceiro que a outra parte gerou uma mensagem, pois ambas

mantem a chave e a forjae possıvel. Os sistemas simetricos garantem entao a confidencialidade,

a autenticidade (entre as duas partes que conhecem a chave) e a integridade, porem nao garan-

tem o nao-repudio (PFLEEGER, 1996). Como exemplos de sistemas criptograficos simetricos

podemos citar o DES (Data Encryption Standard) (SMID; BRANSTAD, 1988), ja ultrapassado

mas ainda utilizado, e o AES (Advanced Encryption Standard) (DAEMEN; RIJMEN, 2002)

(SPECIFICATION. . . , 2001), sucessor do DES.

Na criptografia assimetrica ha duas chaves distintas, de forma que uma nao possa ser cal-

culada a partir da outra num tempo razoavel. Quando uma chavee usada na cifragem, a outra

chave (e apenas ela) deve ser usada na decifragem (SCHNEIER, 1996). Assim, podemos usar

essa caracterıstica para simplificar a comunicacao de mensagens confidenciais em um ambiente

de larga escala. Cada entidade pode gerar individualmente um par de chaves complementares,

manter uma em segredo (chamada dechave privada) e distribuir uma publicamente (chamada

dechave publica). Em um ambiente onde todos disponibilizam suas chaves publicas, manter

a confidencialidadee muito simples: basta pegar a chave publica do destinatario da mensagem,

e usa-la no processo de cifragem. Somente o destinatario podera realizar o processo de deci-

fragem, uma vez que elee o unico que detem a chave privada complementara que cifrou a

mensagem.

14

A criptografia assimetrica tambem possibilita a realizacao de autenticacao com nao-repu-

dio. Na mesma situacao anteriormente descrita, onde todos possuem uma chave publica e uma

privada, se alguem quiser, nao esconder o conteudo de uma mensagem, mas garantir para todos

que foi ele que gerou a mensagem, ele pode simplesmente cifrar a mensagem com a sua chave

privada e disponibilizar a cifra. Isso nao oculta o conteudo da mensagem, pois a chave publica

pode ser usada na decifragem. No entanto, somente a chave publica do remetente sera capaz de

decifrar a mensagem corretamente. Ficam assim garantidos a autenticidade e o nao-repudio da

mensagem. Na verdade, devido ao alto custo computacional da criptografia assimetrica, o que

se faz normalmentee usar uma “versao reduzida”(ou resumo) da mensagem para gerar a cifra.

Essa cifra geradae chamada deassinatura digital, e o resumoe obtida por algoritmos dehash

seguros. Esses algoritmos sao projetados para ser computacionalmente impraticavel descobrir

duas mensagens com o mesmo resumo.

Apesar de resolver muitas situacoes, a criptografia assimetrica apresenta um problema fun-

damental: alguem pode gerar um par de chaves e distribuir a chave publica se passando por ou-

tra pessoa. Esse problemae resolvido pela adocao de umainfra-estrutura de chaves publicas

(ICP). Com o uso de uma ICP, uma pessoa nao mais disponibiliza a sua chave publica, mas

um certificado digital que associa o seu nome a essa chave. Esse certificado deve ser assinado

por uma entidade em que todos confiam: sabem queme, sabem que mantem a sua chave pri-

vada bem segura e sabem que nao assinaria um certificado sem ter certeza da autenticidade do

mesmo. Exemplos de tecnologias para construcao de ICPs sao o X.509 (ITU-T. . . , 1993) e o

SPKI (ELLISON et al., 1999). Exemplos de sistemas assimetricos sao o RSA (Rivest Shamir

Adelman) (RIVEST; SHAMIR; ADLEMAN, 1983) e o ElGamal (ELGAMAL, 1985).

15

3 SERVICOS WEB

ServicosWebsao uma relizacao daArquitetura Orientada a Servicos (AOS). E comum

as pessoas confundirem servicosWebcom AOS, no entanto sao duas coisas distintas. Enquanto

a AOS define uma arquitetura generica, um paradigma conceitual, que se preocupa com o fraco

acoplamento1 e amarracao dinamica2 entre servicos3 (WEERAWARANA et al., 2005, p. 17),

servicosWebformam uma tecnologia que se apoia nos padroes amplamente usados naInternet

— os pricipais sao o HTTP, um protocolo de transferencia de dados (FIELDING et al., 1999), e

o XML, um formato semi-estruturado de representacao de informacoes (BRAY et al., 2006b) —

para prover as caracterısticas da AOS aos servicos. A definicao daWorld Wide Web Consortium

(W3C)4 para servicosWebe a seguinte:

Um servicoWebe um sistema desoftwareprojetado para suportar interope-rabilidade na interacao maquina-maquina sobre uma rede de computadores.Ele possui uma interface descrita em um formato legıvel por um computador(WSDL, especificamente). Outros sistemas interagem com o servicoWebnaforma prescrita na sua interface usando mensagens SOAP [. . . ] (BOOTH etal., 2004).

Este capıtulo comeca fazendo uma introducaoa AOS (secao 3.1), depois descreve o bloco

fundamental dos servicosWeb, o formato XML (secao 3.2), e no fim, contempla os padroes que

definem a intercomunicacao (secao 3.3), a descricao (secoes 3.4 e 3.5) e a publicacao (secao

3.6) de servicosWeb.

1Acoplamentoe a medida de quao interrelacionados sao dois componentes. Acoplamento fraco significa quemodificacoes em um componente causarao pouco impacto em outros componentes, o quee bom para diminuir oesforco dispendido nas alteracoes.

2Amarracaoe a associacao de um identificador (nome) a um objeto (ou servico) qualquer. Amarracao dinamicasignifica que os objetos referenciados pelos identificadores sao encontrados somente durante a execucao do sis-tema.

3Ao longo do texto, o termoservicosera usado para denotar mas servicos desoftwareem geral, e o termoservico Webdenotara a implementacao da AOS

4http://www.w3.org/

16

3.1 ARQUITETURA ORIENTADA A SERVICOS

A AOS e uma arquitetura de sistemas distribuıdos que define o uso de servicos independen-

tes e fracamente acoplados para suportar os requisitos dos processos de negocios e dos usuarios.

Cada servicoe independente dos outros servicos, porem eles podem se intercomunicar para for-

mar processos complexos (WIKIPEDIA, 2006).

Segundo Booth et al. (2004, secao 3.1), um sistema distribuıdo seguindo a AOSe tipica-

mente caracterizado pelas seguintes propriedades:

• visao logica: o servicoe uma visao abstrata e logica dos programas, bases de dados,

processos de negocios, etc..

• orientacaoa mensagens: o servicoe definido formalmente pelas mensagens trocadas entre

o agente provedor e o agente requerente, e nao pelas propriedades internas desses agentes.

A estrutura interna dos agentese totalmente abstraıda na AOS;

• orientacao a descricao: um servicoe descrito por meta-dados processaveis por compu-

tador, e essa descricao deve incluir apenas os detalhes importantes para a utilizacao do

servico, como as operacoes que ele executa, e sua semantica;

• granularidade: servicos tendem a usar poucas operacoes com mensagens relativamente

grandes e complexas;

• orientacaoa redes: servicos tendem a ser orientados para o uso em redes de computado-

res, apesar de nao ser um requerimento absoluto;

• independencia de plataforma: as mensagens sao enviadas em formato independente de

plataforma (sistema subjacente ao servico) e padronizado, especificado na interface des-

critiva do servico.

Os princıpios de funcionamento de um sistema que segue a AOS estao ilustrados na figura

2. Primeiramente,e necessario prover uma definicao abstrata do servico, permitindo que um

cliente (agente requerente) possa fazer invocacoes adequadamente. Depois, o agente provedor

deve publicar essas definicoes em um local acessıvel aos clientes, onde eles possam fazer buscas

para encontrar servicos de forma dinamica. Em terceiro lugar, um cliente deve localizar os

provedores que disponibilizam o servico que satizfaz suas necessidades, para posteriormente

fazer a invocacao ao servico escolhido (WEERAWARANA et al., 2005).

17

Figura 2: Interacao entre as entidades da AOS (CAMARGO, 2006, apud (BOOTH et al., 2004)).

Figura 3: Arquitetura dos servicosWeb(CAMARGO, 2006).

Para que esse mecanismo publicar/localizar/invocar funcione corretamente,e necessario

que se definam padroes que governem todas as interacoes entre as entidades. Nesse sentido,

os servicosWebapresentam uma boa proposta de materializacao da AOS (figura 3), e a seguir

serao apresentados os padroes utilizados por essa tecnologia.

3.2 O FORMATO XML

XML e um acronimo paraeXtensible Markup Language(Linguagem de Marcacao Ex-

tensıvel). E uma recomendacao da W3C (BRAY et al., 2006b) que define um formato padrao

independente de plataforma para a representacao de dados e documentos estruturados. Foi pro-

jetada para ser amplamente utilizada naWeb, e atualmentee um padrao de facto. O formato

XML impoe restricoesa estrutura elayoutdos dados, mas sem restringir quais entidades podem

ser representadas, o que faz do o XML uma linguagem flexıvel e extensıvel.

A sintaxe do XMLe semelhante a de outras linguagens de marcacao mais antigas, como

18

HTML (RAGGETT; HORS; JACOBS, 1999). Umelementopossui uma marcacao inicial e

uma final (exceto por elementos vazios, que podem ter apenas uma marcacao), e o que estiver

aninhando entre essas marcacoese oconteudo do elemento. O conteudo de um elemento pode

ser constituıdo de outros elementos ou de texto plano. Na marcacao inicial de um elemento

podem ser definidos aindaatributos desse elemento na forma de pares nome-valor.

1 <?xml version="1.1"?>2 3 <acervo xmlns="http://livros.exemplos.com/">4 <titulo nome="Karate-Kid 3">5 <exemplares>6 <exemplar id="1132-3324">7 <dataCompra>2005-10-23</dataCompra>8 <ultimaLocacao>2006-01-18</ultimaLocacao>9 <disponivel />

10 </exemplar>11 <exemplar id="1132-3325">12 <dataCompra>2005-10-23</dataCompra>13 <ultimaLocacao>2006-01-23</ultimaLocacao>14 <locado>15 <cliente>Luis I. L. da Silva</cliente>16 <dataEntrega>2006-01-24</dataEntrega>17 </locado>18 </exemplar>19 </exemplares>20 <categoria>acervo</categoria>21 <estilo>aventura</estilo>22 <reservas />23 </titulo>24 </acervo>

Figura 4: Exemplo de documento XML.

A figura 4 mostra um exemplo de documento XML. Todo documento XML deve conter

umelemento raiz, que nao esteja contido em nenhum outro elemento (No exemplo dado, o ele-

mento raize<acervo>) Al em disso, todo elemento deve estar imediatamente contido em apenas

um elemento, chamado de elementopai. (No exemplo,<titulo> e pai de<exemplares>, e o

segundoe filho do primeiro.) A sintaxe para a definicao de atributose nome= “valor” (Como

no atributonome do elemento<titulo>, na linha 4 do exemplo). Alem dessas construcoes, o

XML ainda possui comentarios, colocados entre (linha 2 do exemplo), e instrucoes

de processamento, limitadas por<? e?> (linha 1 do exemplo). Esse exemplo contem, alem das

construcoes basicas do XML, uma definicao de espaco de nomes (no atributoxmlns="...", na

linha 3) de acordo com a extensao do XML chamadaXML Namespaces(BRAY et al., 2006a).

Essa extensao sera explicada brevemente na subsecao 3.2.1.

Al em da sintaxe XML, que define documentosbem-formados, ainda pode ser feita uma

19

validacao do documento, que dira se a estrutura contida no documento satisfaz alguma restri-

cao. Restricoes estruturais — como a ordem e o aninhamento das marcacoes, quais atributos um

elemento deve ter — e de tipo — o conteudo de um elemento deve ser uma data, por exemplo —

sao definidas por meio de esquemas formais, que serao usados para dizer se um exemplar de do-

cumentoe ou nao valido. As principais linguagens para a definicao de esquemas de documentos

XML sao DTD (Document Type Definition) (BRAY et al., 2006b) eXML Schema(FALLSIDE;

WALMSLEY, 2004). Oultimo, por ser mais utilizado, sera apresentado na subsecao 3.2.3.

3.2.1 ESPACOS DE NOMES EM XML

Segundo Bray et al. (2006a),

espacos de nomes (namespaces) em XML provem um metodo simples paraqualificar nomes de elementos e atributos usadso em documentos XML asso-ciando esses nomes com espacos de nomes identificados por referencias IRI(DUERST; SUIGNARD, 2005).

A especificacao de espacos de nomes preve a utilizacao denomes expandidos, compostos

de nome locale espaco de nomes, a fim de tornar possıvel a construcao devocabularios de

marcacoes. Esses nomes expandidos evitam que haja colisao de termos entre documentos de

organizacoes diferentes (BRAY et al., 2006a).

1 <ns:doc xmlns:ns="http://exemplo.doc.com.br/ns" ns:tipo="exemplo">2 <name xmlns="http://exemplo.doc.com.br/nome">3 Documento4 </name>5 </ns:doc>

Figura 5: Exemplo de documento XML com definicoes de espacos de nomes.

A sintaxe para a definicao de um espaco de nomese mostrada na figura 5. Na linha 1 esta

sendo definido o espaco de nomeshttp://exemplo.doc.com.br/ns, e atribuindo esse espaco

ao prefixons. O elementons:doc e qualificado por esse espaco de nomes definido. Na linha

2, esta sendo definido o espaco de nomeshttp://exemplo.doc.com.br/nome, porem este

nao se esta sendo atribuıdo a nenhum prefixo. Nesse caso, os elementos e atributos sem prefixo

estarao automaticamente qualificados por esse espaco de nomes (espaco de nomes padrao).

O escopo de uma declaracao de espaco de nomes vai desde a marcacao inicial do elemento

onde esta sendo declarada ate a marcacao final correspondente, exceto no escopo dos elementos

que redefinam o prefixo utilizado (o mesmo vale para o espaco de nomes padrao) (BRAY et al.,

2006a).

20

Apesar de serem usados IRIs nos nomes dos espacos de nomes, esses IRIs nao precisam

apontar para nenhum recurso, sao apenas usados para qualificar um vocabulario.

3.2.2 XML INFORMATION SET

A especificacao XML Information Set(COWAN; TOBIN, 2004)e uma recomendacao da

W3C que define um conjunto abstrato de dados — chamadoinfoset— com o objetivo de prover

um conjunto de definicoes consistente para o uso em outras especificacoes quando precisarem

se referira informacao contida em um documento XML bem-formado.

Um documento XML possui uminfosetse for bem-formado (mas nao necessariamente

valido) e se estiver em conformidade com a especificacao dos espacos de nomes (BRAY et al.,

2006a) (no entanto, nenhum nome de espaco de nomes pode conter uma URI relativa, como

esta dito em (HOLLANDER; SPERBERG-MCQUEEN, 2000)). Uminfosete constituıdo de

diversos itens de informacao, que podem ser de onze tipos distintos, cada tipo representando

uma construcao basica do XML. Cada item de informacao possui um conjunto de propriedades

derivadas da estrutura do documento XML.

Os principais tipos de itens de informacao sao (COWAN; TOBIN, 2004):

• item de informacao de documento: representa um documento XML como todo. Sua

principais propriedades sao[children] , um conjunto que contem o item de informacao do

elemento raiz do documento, os itens de informacao de instrucao de processamento e de

comentario externos ao elemento raiz; e[document element], o item de informacao do

elemento raiz do documento;

• item de informacao de elemento: representa um elemento. Suas principais propriedades

sao[namespace name], o nome do espaco de nomes do elemento;[local name], o nome

local do elemento;[prefix] , o prefixo do espaco de nomes do elemento;[children] , um

conjunto ordenado de itens de informacao que podem ser de elemento, instrucao de pro-

cessamento, referencia de entidade nao-expandida, caractere e comentario; [attributes] ,

um conjunto de itens de informacao de atributo;[namespace attributes], um conjunto

de itens de informacao de atributo que contem as declaracoes de espacos de nomes deste

elemento;[in-scope namespaces], o conjunto de espacos de nomes em vigor neste ele-

mento; e[parent] , o item de informacao do elemento ou do documento que contem este;

• item de informacao de atributo: representa um atributo de um elemento, incluindo

declaracoes de espacos de nomes e os atributos implıcitos (definidos por um valor pa-

drao). Suas principais propriedades sao [namespace name], [local name] e [prefix] ,

21

similares ao item de informacao de elemento;[normalized value], o valor do atributo

normalizado (BRAY et al., 2006b, sec. 3.3.3);[specified], que define se o atributo foi

especificado na marcacao do elemento ou foi atribuıdo implicitamente pelo tipo do ele-

mento;[attribute type] , o tipo do atributo; e[owner element], o item de informacao do

elemento que contem este atributo;

Os outros sao intens de informacao de instrucao de processamento, de referencia de enti-

dade nao-expandida, de caractere, de comentario, de declaracao de tipo de documento (DTD),

de entidade nao analisada (unparsed), de notacao, e de espaco de nomes.

3.2.3 XML SCHEMA

A XML Schema(FALLSIDE; WALMSLEY, 2004) e uma linguagem, desenvolvida pela

W3C, para a definicao de estruturas e tipos de documentos XML. O objetivoe similar ao DTD,

porem oXML Schemausa sintaxe XML ee muito mais poderoso (WEERAWARANA et al.,

2005). Enquanto o DTD apenas permite definir a estrutura de documentos, oXML Schema

tambem permite especificar tipos de dados. Essa mistura torna oXML Schemamais complexo

que o DTD, no entanto ha muitas ferramentas que facilitam seu uso no desenvolvimento de

esquemas.

3.3 PROTOCOLO DE COMUNICACAO ENTRE SERVICOSWEB- SOAP

SOAPe uma recomendacao da W3C que atualmente esta na versao 1.2 e

“[. . . ] prove a definicao da informacao baseada em XML que pode ser usadana troca de informacao estruturada e tipada entre servidores em um ambientedistribuıdo descentralizado”(MITRA, 2003).

Essa especificacao diz como a informacao deve ser formatada a fim de ser transportada de

um ponto a outro, no entanto nao define nenhum protocolo de transporte ou de roteamento.

SOAP define apenas um paradigma de troca de mensagensone-waysem estado. Essas men-

sagens podem ser combinadas para formar padroes complexos de comunicacao e se usar de

qualquer benefıcio de protocolos inferiores (MITRA, 2003).

Uma mensagem SOAPe um elemento XML chamadoEnvelope, que contem dois subele-

mentos:Header(cabecalho) e Body(corpo). O conteudo do cabecalho e do corpoe definido

pela aplicacao, no entanto a especificacao SOAP diz como esses elementos devem ser mani-

pulados. O cabecalhoe um mecanismo opcional de extensao, que deve ser usado para passar

22

1 <?xml version="1.0" ?>2 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">3 <env:Header>4 <p:oneBlock xmlns:p="http://example.com"5 env:role="http://example.com/Log">6 ...7 </p:oneBlock>8 <q:anotherBlock xmlns:q="http://example.com"9 env:role="http://www.w3.org/2003/05/soap-envelope/role/next">

10 ...11 </q:anotherBlock>12 <r:aThirdBlock xmlns:r="http://example.com"13 env:mustUnderstand="true">14 ...15 </r:aThirdBlock>16 </env:Header>17 <env:Body >18 ...19 </env:Body>20 </env:Envelope>

Figura 6: Exemplo de mensagem SOAP (MITRA, 2003).

informacoes de controle, nao inerentesa informacao sendo transmitida — como informacoes de

seguranca, por exemplo. Os subelementos imediatos do cabecalho sao chamados deblocos de

cabecalhoe podem ser enderecadosa um no especıfico no caminho percorrido pela mensagem

entre o remetente e o destinatario final (MITRA, 2003). Cada bloco de cabecalho pode possuir

dois atributos que indicam a forma como devem ser processados. O atributomustUnderstand

indica se o receptor do bloco deve saber como processa-lo ou pode ignora-lo. O atributorole

indica para queme destinado o bloco de cabecalho. O corpo da mensageme um elemento

obrigatorio que contem a informacao enderecada ao destinatario final. A figura 6 mostra um

exemplo de mensagem SOAP.

3.4 DESCRICAO FUNCIONAL DE SERVICOSWEB- WSDL

WSDL e uma linguagem criada para descrever servicosWeb. A WSDL esta na versao 2.0 e

e atualmente candidata a recomendacao do W3C. A WSDLe uma linguagem XML que define

os servicosWebem dois nıveis distintos (CHINNICI et al., 2006): o nıvel abstrato, onde o

servicoe descrito em termos das mensagens que envia e recebe, e o nıvel concreto, onde as

mensagens sao associadas a um mecanismo de transporte.

No nıvel de descricao abstrato, as mensagens sao descritas de forma abstrata (dentro do

elementotypes), independente do formato subjacente, usando um sistema de tipos comoXML

Schema(CHINNICI et al., 2006). Essas mensagens podem ser associadas para formarpadroes

23

1 <?xml version="1.0" encoding="utf-8" ?>2 <description3 xmlns="http://www.w3.org/2006/01/wsdl"4 targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"5 xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"6 xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"7 xmlns:wsoap= "http://www.w3.org/2006/01/wsdl/soap"8 xmlns:soap="http://www.w3.org/2003/05/soap-envelope"9 xmlns:wsdlx= "http://www.w3.org/2006/01/wsdl-extensions">

10

11 <types>12 <xs:schema13 xmlns:xs="http://www.w3.org/2001/XMLSchema"14 targetNamespace="http://greath.example.com/2004/schemas/resSvc"15 xmlns="http://greath.example.com/2004/schemas/resSvc">16 <xs:element name="checkAvailability" type="tCheckAvailability"/>17 <xs:complexType name="tCheckAvailability">18 <xs:sequence>19 <xs:element name="checkInDate" type="xs:date"/>20 <xs:element name="checkOutDate" type="xs:date"/>21 <xs:element name="roomType" type="xs:string"/>22 </xs:sequence>23 </xs:complexType>24 <xs:element name="checkAvailabilityResponse" type="xs:double"/>25 <xs:element name="invalidDataError" type="xs:string"/>26 </xs:schema>27 </types>28

29 <interface name = "reservationInterface" >30 <fault name = "invalidDataFault"31 element = "ghns:invalidDataError"/>32 <operation name="opCheckAvailability"33 pattern="http://www.w3.org/2006/01/wsdl/in-out"34 style="http://www.w3.org/2006/01/wsdl/style/iri"35 wsdlx:safe = "true">36 <input messageLabel="In"37 element="ghns:checkAvailability" />38 <output messageLabel="Out"39 element="ghns:checkAvailabilityResponse" />40 <outfault ref="tns:invalidDataFault" messageLabel="Out"/>41 </operation>42 </interface>

Figura 7: Parte abstrata de uma descricao WSDL (BOOTH; LIU, 2006).

24

de troca de mensagens(em ingles,Message Exchange Patterns- MEPs) por meio de operacoes

abstratas (elementooperation). Uma interface (elementointerface) reune diversas operacoes,

sem se preocupar com o protocolos subjacentes usados para o transporte das mensagens. A

figura 7 apresenta um exemplo de definicao abstrata de servico.

1 <binding name="reservationSOAPBinding"2 interface="tns:reservationInterface"3 type="http://www.w3.org/2006/01/wsdl/soap"4 wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">5 <fault ref="tns:invalidDataFault"6 wsoap:code="soap:Sender"/>7 <operation ref="tns:opCheckAvailability"8 wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>9 </binding>

10

11 <service name="reservationService"12 interface="tns:reservationInterface">13 <endpoint name="reservationEndpoint"14 binding="tns:reservationSOAPBinding"15 address ="http://greath.example.com/2004/reservation"/>16 </service>17

18 </description>

Figura 8: Parte concreta de uma descricao WSDL (BOOTH; LIU, 2006).

No nıvel concreto, uma amarracao (elementobinding) define os protocolos subjacentes

em detalhe para uma ou mais interfaces. Umendpointassocia um endereco de rede a uma

amarracao. E finalmente, um servico (elementoservice) agrupaendpointsque implementam

uma interface comum (CHINNICI et al., 2006). A figura 8 ilustra a definicao concreta de um

servico usando WSDL.

3.5 POLITICAS EM SERVICOSWEB

A WS-Policyfoi desenvolvida em conjunto por diversas empresas e submetida em 2006

para ser padronizada pela W3C (BAJAJ et al., 2006b, 2006a). O objetivoe fornecer uma forma

simples de expressar requisitos nao-funcionais de servicosWebna forma de polıticas. Alem

disso, a especificacao propoe procedimentos para transformar uma expressao de uma polıtica

em uma forma normal e para interseccionar polıticas distintas.

A unidade basica para expressar um requisitoe umaassercao de polıtica, que expressa

semanticas especıficas de domınio. O tipo de uma assercao e identificado pelo nome do ele-

mento qualificado pelo espaco de nomes do mesmo. Assercoes podem ser combinadas em

alternativas de polıtica, cada alternativa definindo um conjunto de requisitos que devem ser

25

satisfeitos em conjunto para satisfazer a alternativa. Umapolıtica, por sua vez,e um conjunto

de alternativas de polıtica, e satisfazer a polıtica significa satisfazer alguma dessas alternativas

(BAJAJ et al., 2006b).

1 <wsp:Policy2 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"3 xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" >4 <wsp:ExactlyOne>5 <wsp:All>6 <sp:Basic256Rsa15 />7 </wsp:All>8 <wsp:All>9 <sp:TripleDesRsa15 />

10 </wsp:All>11 </wsp:ExactlyOne>12 </wsp:Policy>

Figura 9: Exemplo de polıtica expressa na forma normal definida naWS-Policy(BAJAJ et al.,2006b).

As polıticas sao expressas por meio de umXML infosetdefinido na especificacao. A fi-

gura 9 traz um exemplo de polıtica na forma normal. Nesse exemplo ha duas alternativas de

polıtica, cada uma encapsulada por um elemento<wsp:All>, indicando que todas as assercoes

filhas devem ser satisfeitas. As alternativas estao contidas no elemento<wsp:ExactlyOne>,

indicando que uma das alternativas deve ser satisfeita. Esses operadores podem ser compostos

de formas diferentes, e a especificacao define diversas construcoes com a finalidade de facilitar

a escrita e o entendimento das polıticas, como assercoes opcionais, identificacao e referencias

para polıticas, etc..

A especificacaoWS-Policynao define nenhum mecanismo para anexar uma polıtica a um

servicoWeb. Para isso existe a especificacaoWS-PolicyAttachment(BAJAJ et al., 2006a), que

sera abordada na proxima secao.

3.5.1 ANEXOS DE POLITICA

A WS-PolicyAttachmentdefine mecanismos gerais para se anexar uma expressao de polıtica

a um sujeito (uma operacao, uma mensagem, etc.). Sao propostos dois metodos parar tal: um

metodoe especıfico para descricoes em XML e preve o uso de um atributo ou subelemento que

referencia a expressao da polıtica que se deseja associar; o outro metodoe mais generico, e

usa um formato XML para associar um polıtica a um sujeito independente da sua definicao ou

representacao (BAJAJ et al., 2006a).

A parte (a) da figura 10 mostra um exemplo de anexacao de uma polıtica a um elemento

26

1 <MyElement wsp:PolicyURIs="2 http://www.fabrikam123.example.com/policies#RmPolicy3 http://www.fabrikam123.example.com/policies#X509EndpointPolicy" />4

5 (a)6

7 <MyElement>8 <wsp:PolicyReference9 URI="http://www.fabrikam123.example.com/policies#RmPolicy" />

10 <wsp:PolicyReference11 URI="http://www.fabrikam123.example.com/policies#X509EndpointPolicy" />12 <MyElement/>13

14 (b)

Figura 10: Exemplos de anexacao de polıtica a um elemento XML de acordo com aWS-PolicyAttachment(BAJAJ et al., 2006a).

XML usando o atributoPolicyURIs. O valor desse atributo sao URIs separadas por espaco,

e cada URI aponta para uma polıtica. A parte (b) mostra a aplicacao da mesma polıtica sobre

o mesmo elemento, porem por meio do elemento<PolicyReference>. Os dois exemplos sao

equivalentes quanto a polıtica que sera aplicada sobre o elemento<MyElement>.

1 <wsp:PolicyAttachment>2 <wsp:AppliesTo>3 <wsa:EndpointReference xmlns:fabrikam="..." >4 <wsa:Address>http://www.fabrikam123.example.com/acct</wsa:Address>5 <wsa:PortType>fabrikam:InventoryPortType</wsa:PortType>6 <wsa:ServiceName>fabrikam:InventoryService</wsa:ServiceName>7 </wsa:EndpointReference>8 </wsp:AppliesTo>9 <wsp:PolicyReference

10 URI="http://www.fabrikam123.example.com/policies#RmPolicy" />11 </wsp:PolicyAttachment>

Figura 11: Exemplos de anexacao de polıtica a umendpoint(descrito segundo aWS-Addressing(BOX et al., 2004)) usando o mecanismo de anexacao externa daWS-PolicyAttachment(BAJAJet al., 2006a).

A figura 11 mostra um exemplo de anexacao de uma polıtica a um servicosWebpor meio

de umendpoint(BOX et al., 2004). O elemento<AppliesTo> contem os sujeitos que terao

a polıtica anexada. O conteudo desse elementoe especıfico das aplicacoes, contanto que nao

contradigam a semantica daWS-Policy. Os elementos seguintes devem conter as expressoes de

polıtica ou, como no exemplo, referencias para elas. Depoise possıvel adicionar um elemento

<Security> segundo definido naWS-Security(NADALIN et al., 2006b) (veja secao 4.2), que

pode conter informacoes de seguranca como assinaturas digitais, por exemplo (BAJAJ et al.,

2006a).

27

A WS-PolicyAttachmentainda preve meios mais especıficos para anexar polıticas a docu-

mentos WSDL e entidades UDDI.

3.6 SERVICO DE REGISTRO E DIVULGACAO DE SERVICOSWEB -UDDI

Um servicoWeb tem sua funcionalidade expressa em WSDL, suas caracterısticas nao-

funcionais como expressoes de polıtica e suas mensagens utilizam o padrao SOAP. Essa es-

truturae suficiente em muitas situacoes, no entanto, ha casos em que se deseja tambem um me-

canismo para divulgar o servico, fazer as suas descricoes tecnicas e nao-tecnicas alcancarem os

clientes potencias. Para isso surgiu o UDDI (CLEMENT et al., 2004) (Universal Description,

Discovery and Integration- Descicao, Descoberta e Integracao Universais), uma especificacao

daOrganization for the Advancement of Structured Information Standards(OASIS)5, que for-

nece um modelo de dados e diversas interfaces de servicos para a consulta e o gerenciamento

das informacoes a respeito dos servicosWebe seus provedores.

O modelo de dados do UDDI define algumas entidades — estruturas de dados persisten-

tes — que armazenam informacoes sobre os servicosWebe seus provedores. As principais

entidades sao (CLEMENT et al., 2004):

• businessEntity: descreve uma organizacao provedora de servicosWeb. Contem informa-

coes nao-tecnicas, como nomes, informacoes para contato e informacao de classificacao;

• businessService: descreve um conjunto de servicosWebrelacionados, oferecidos pela

mesma organizacao, descrita por umabusinessEntity. Novamente, nao contem infor-

macoes tecnicas a respeito dos servicos, apenas nomes, descricoes e informacoes de

classificacao;

• bindingTemplate: descreve as informacoes tecnicas necessarias para se utilizar um servico

Webespecıfico. Contem o ponto de acesso ao servico, ou um redirecionamento para

algum local que levara ao ponto de acesso;

• tModel: descreve um “modelo tecnico”, um conceito reusavel como um tipo de servico

ou um protocolo.

Os conjuntos de interfaces para manipulacao dos dados, definidos para padronizar o com-

portamento e as comunicacoes entre as implementacoes do UDDI, sao de dois tipos: conjuntos

5http://www.oasis-open.org/

28

de interfaces de no e conjuntos de interfaces de clientes. Os conjuntos de interfaces de no de-

finem como ocorre a manipulacao dos dados sobre os servicos, e um conjunto de servicosWeb

que suporte pelo menos um desses conjuntos de interfacese chamado deno UDDI. Diversos

nos UDDI podem ser combinados para formarregistros UDDI, e cada no do registro tem acesso

a uma copia logica completa dos dados contidos no registro.

29

4 SEGURANCA EM SERVICOS WEB

Pelo fato dos servicosWebestarem profundamente baseados no padrao XML, as especifi-

cacoes de seguranca para os servicosWebse utilizam das espeficicacoes de seguranca em XML.

Na proxima secao (4.1) os padroes de seguranca para XML sao apresentados. Da secao 4.2 em

diante, sao abordadas especificacoes de seguranca especıficas de servicosWeb.

4.1 ESPECIFICACOES DE SECURANCA PARA XML

4.1.1 XML-SIGNATURE

O padrao XML-Signature(BARTEL et al., 2002) define uma sintaxe XML padrao para

representar uma assinatura digital e regras para gerar e validar essas assinaturas (REAGLE,

1999). O objeto de uma assinatura XML nao precisa ser um documento XML, pode ser qual-

quer conteudo digital do qual se queira a garantir integridade e autenticidade. No contexto de

servicosWeb, no entanto, essas assinaturas, na maioria daz vezes se referem a documentos ou

partes de documentos XML.

Os algoritmos de assinatura digital sao sensıveis a qualquer alteracao no objeto assinado,

assim, a simples adicao de um espaco em branco em um documentoe suficiente para que a

assinatura seja totalmente diferente. Issoe um problema quando se esta trabalhando com um

formato semi-estruturado, como o XML, que permite que um mesmo objeto seja expresso de

formas diferentes. Para resolver esses problema, a especificacao XML-Signaturepreve o uso

de metodos de canonizacao. Para documentos XML, a recomendacao da W3Ce o algoritmo

proposto por Boyer (2001).

A figura 12 apresenta uma assinatura digital em XML. Esse exemplo ilustra a assinatura

de um documento XML (na verdade, a especificacao XHTML 1.0) referenciado por uma URL.

Uma assinatura digital fica encapsulada pelo elemento<Signature>. Dentro deste elemento,

o elemento<SignedInfo> contem as informacoes sobre os objetos que serao assinados, o

elemento<SignatureValue> contem a assinatura do elemento<SignedInfo> e o elemento

30

1 <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">2 <SignedInfo>3 <CanonicalizationMethod4 Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>5 <SignatureMethod6 Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>7 <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">8 <Transforms>9 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

10 </Transforms>11 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>12 <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>13 </Reference>14 </SignedInfo>15 <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>16 <KeyInfo>17 <KeyValue>18 <DSAKeyValue>19 <P>...</P><Q>...</Q><G>...</G><Y>...</Y>20 </DSAKeyValue>21 </KeyValue>22 </KeyInfo>23 </Signature>

Figura 12: Exemplo de assinatura digital segundo aXML-Signature(BARTEL et al., 2002).

<KeyInfo> contem informacoes sobre a chave que deve ser usada para verificar a assinatura. O

elemento<SignedInfo> contem as seguintes informacoes:

• um metodo de canonizacao XML aplicado no elemento<SignedInfo> para gerar a assi-

natura (elemento<CanonicalizationMethod>);

• um metodo de assinatura, que informa qual o algoritmo de assinatura usado (elemento

<SignatureMethod>);

• uma referencia (elemento<Reference>) para cada objeto assinado. cada referencia

ainda contem o algoritmo usado para calcular o resumo do objeto referenciado (elemento

<DigestMethod>), os resumos desses objetos (elemento<DigestValue>) e os pre-pro-

cessos que sao aplicados aos objetos antes dos resumos serem computados (elemento

<Transforms>).

O elemento<KeyInfo> e opcional, pois o emissor da assinatura pode nao desejar revelar

informacoes sobre a chave para todas as partes envolvidas no processamento do documento.

Al em disso, o contexto de utilizacao e as aplicacoes podem definir a chave a ser usada (BAR-

TEL et al., 2002). Esse elemento pode conter uma ou mais chaves (<KeyData>), pode con-

ter nomes associados a chaves (<KeyName>), URIs de onde as chaves devem ser recuperadas

31

(<RetrievalMethod>), certificados ou cadeias de certificados de diversas ICPs (<X.509Data>,

<SPKIData>, etc.), ou entao alguma extensao definida pelo desenvolvedor de aplicacao.

A verificacao da assinatura se da em dois estagios: primeiramente cada resumo contido

em um elemento<Reference> e validado de acordo com o objeto referenciado (aplicando-se

devidamente os pre-processos e usando o algoritmo indicado); depois a assinatura contida no

elemento<SignatureValue> e validada contra o elemento<SignedInfo>.

4.1.2 XML ENCRYPTION

A especificacao XML Encryption(IMAMURA; DILLAWAY; SIMON, 2002) prov e uma

sintaxe XML e um processo para cifrar conteudo digital, incluindo porcoes de documentos

XML e mensagens de protocolo (REAGLE, 2002).

1 <EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’2 Type=’http://www.w3.org/2001/04/xmlenc#Element’/>3 <EncryptionMethod4 Algorithm=’http://www.w3.org/2001/04/xmlenc#des-cbc’/>5 <ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>6 <ds:KeyName>John Smith</ds:KeyName>7 </ds:KeyInfo>8 <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>9 </EncryptedData>

Figura 13: Exemplo de cifra segundoXML Encryption(IMAMURA; DILLAWAY; SIMON,2002).

A sintaxe de uma cifra expressa segundo essa especificacao esta exemplificada na figura

13. O elemento raiz de uma cifrae<EncrypteData> (linha 1). Esse elemento possui o atributo

opcionalType, que indica qual o tipo de informacao esta cifrada. Dois tipos sao definidos pela

especificacao: um tipo para elementos XML (como no exemplo, linha 2) e um para o conteudo

de um elemento XML (http://www.w3.org/2001/04/xmlenc#Content). Outros dois atri-

butos opcionais podem ser usados para definir o formato da informacao cifrada:MimeType e

Encoding. O elemento filho<EncryptionMethod> contem informacoes sobre o processo de

cifragem e o elemento<KeyInfo> e o mesmo usado noXML-Signature. Ambos sao opcionais,

pois tanto o algoritmo usado quanto a chave podem ser especificados pelas aplicacoes ou pelo

contexto de utilizacao da cifragem. O elemento<CipherData> e obrigatorio e pode conter

o valor da cifra (pelo elemento<CipherValue>, como na linha 8 do exemplo) ou pode con-

ter uma referencia para esse valor (pelo elmento<CipherReference>, que funciona de forma

parecida com o<RetrievalMethod> doXML-Signature).

A XML Encryptiondefine ainda uma sintaxe XML especial para o caso em que se deseja

32

1 <EncryptedData Id=’ED’2 xmlns=’http://www.w3.org/2001/04/xmlenc#’>3 <EncryptionMethod4 Algorithm=’http://www.w3.org/2001/04/xmlenc#aes128-cbc’/>5 <ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>6 <ds:RetrievalMethod URI=’#EK’7 Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>8 <ds:KeyName>Sally Doe</ds:KeyName>9 </ds:KeyInfo>

10 <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>11 </EncryptedData>12

13 <EncryptedKey Id=’EK’ xmlns=’http://www.w3.org/2001/04/xmlenc#’>14 <EncryptionMethod15 Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>16 <ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>17 <ds:KeyName>John Smith</ds:KeyName>18 </ds:KeyInfo>19 <CipherData><CipherValue>xyzabc</CipherValue></CipherData>20 <ReferenceList>21 <DataReference URI=’#ED’/>22 </ReferenceList>23 <CarriedKeyName>Sally Doe</CarriedKeyName>24 </EncryptedKey>

Figura 14: Exemplo de chave cifrada segundo aXML Encryption(IMAMURA; DILLAWAY;SIMON, 2002).

cifrar uma chave. A figura 14 mostra um exemplo em que uma informacao qualquere cifrada

usando uma chave AES de 128 bits, que esta cifrada dentro do mesmo documento. A chave

AES esta cifrada pela chave publica RSA do receptor. A chave simetrica usada para cifrar a

informacaoe indicada pelo atributoURI do elemento<RetrievalMethod> (linha 6), e o nome

associadoa chave esta especificado no elemento<KeyName> (linha 8). A diferenca do elemento

<EncryptedKey> para o elemento<EncryptedData> e que o primeiro: pode conter uma lista

de referencias que indica quais cifras (<EncryptedKey>’s ou<EncryptedData>’s) foram gera-

das por esta chave (linhas 20 a 22 do exemplo); pode conter tambem o nome associadoa chave

cifrada (linha 23 do exemplo); e pode ter um atributoRecipient, cujo conteudoe especificado

pela aplicacao, dizendo qual o receptor esperado para a chave.

Al em de definir a sintaxe para respresentar as informacoes cifradas, a especificacao tam-

bem padroniza os algoritmos e os formatos de dados que devem ser usados durante a cifra-

gem e a decifragem dos dados, com o objetivo de prover maior interoperabilidade entre as

implementacoes.

33

4.2 WS-SECURITY

A WS-Securitye uma especificacao padronizada pela OASIS (NADALIN et al., 2006b)

que define mecanismos para prover confidencialidade, integridade e inclusao detokens de

seguranca1 as mensgens SOAP. A especificacao define o bloco de cabecalho<Security> —

que pode conter diversos tipos de informacoes de seguranca, como assinaturas digitais, dados

cifrados, certificados digitais, etc. — e como utiliza-lo para prover as caracterısticas citadas.

A especificacao preve o uso dos padroesXML-SignatureeXML Encryption(secoes 4.1.1 e

4.1.2) como meios para prover integridade e confidencialidadeas mensagens SOAP, assinando

e/ou cifrando o corpo, o cabecalho, ou quaisquer combinacoes de suas partes.

Podem haver diversos blocos<Security> em um mesmo cabecalho SOAP, no entanto cada

bloco deve ser destinado a um receptor diferente, por meio do atributorole. Pode haver um

unico bloco<Security> sem um atributorole, cujo conteudo e destinado a todos os nos de

processamento. Cada no deve processar o bloco<Security> destinado a ele, podendo remover

o bloco ou adicionar outros.

Dois tipos detokende seguranca genericos sao previstos na especificacao daWS-Security.

Sao o <UsernameToken>, que serve para transmitir uma credencial de nome de usuario, e

<BinarySecurityToken>, que servem para transmitir credenciais que nao usam o formato

XML (como certificados X.509 e SPKI, eKerberos tickets).

O elemento<Security> foi projetado para ser extensıvel, de forma que novas especifi-

cacoes de seguranca possam ser usadas em conjunto com aWS-Security. Ja existem padroes

OASIS (NADALIN et al., 2006c, 2006d, 2006a; MONZILLO et al., 2006) que provem metodos

para utilizar as tecnologias X.509, SAML, Kerberos, etc. nas mensagens SOAP, e sao chamados

deperfis detoken(token profiles).

4.3 WS-TRUST

A WS-Trust(ANDERSON et al., 2005b)e uma proposta que tem por objetivo habilitar

aplicacoes a construir trocas de mensagens SOAP confiaveis. Ela estende aWS-Securitycom

mecanismos para facilitar a emissao e a disseminacao detokensde seguranca.

O modelo de seguranca daWS-Trustsupoe que um servico exija que uma mensagem che-

1Um tokende segurancae definido em diversas especificacoes (NADALIN et al., 2006b; ANDERSON et al.,2005b, 2005a) como sendo um conjunto nao-vazio de assercoes feitas acerca de um cliente, servico ou outrorecurso (por exemplo, nome, identidade, chave, grupo, privilegio, possibilidade, etc.).

34

gando prove um conjunto de afirmacoes. Essas exigencias podem ser expressas na forma de

expressoes de polıtica WS-Policy, e uma mensagem que nao siga a polıtica determinada deve

ser descartada pelo servico. Quando um cliente deseja invocar esse servico, e nao possui as

credenciais necessarias, ele deve conhecer alguma autoridade que possa consultar na tentativa

de obter as credenciais. Essa autoridade (chamada deSecurity Token Service- STS), por sua

vez, pode ter uma determinada polıtica, e exigir que o cliente prove algumas afirmacoes para

poder emitir as credenciais.

Figura 15: Modelo de seguranca daWS-Trust(CAMARGO, 2006, apud (ANDERSON et al.,2005b)).

A figura 15 ilustra esse modelo. Ela representa todas as entidades como servicosWeb,

mostrando que um cliente pode ser tambem um servicoWeb, e que o STSe um servicoWeb.

As setas indicam possıveis caminhos de comunicacao. Dessa forma, pelo caminho 2 o cliente

pode tomar conhecimento da polıtica do servicoWeb. Ele pode pedir ostokensao STS pelo

caminho 1, ou entao de forma indireta, e faz a requisicao pelo caminho 2, mostrando ostokens

ao servicoWeb. O servico requisitado pode confiar no bilhete (gracas a uma assinatura digital,

por exemplo), ou entao pode validar ostokensapresentados pelo cliente consultando o STS pelo

caminho 3.

Quando um cliente faz um pedido a um STS, este verifica se os requerimentos da polıtica

estao sendo cumpridos, e caso estejam, o cliente recebe uma resposta contendo ostokens. A

WS-Trustdefine uma interface padrao para as mensagens de requisicao e resposta detokens

de seguranca. Um pedidoe expresso pelo tipo<wst:RequestSecurityToken> (RST) e uma

resposta pelo tipo<wst:RequestSecurityTokenResponse> (RSTR).

A figura 16 mostra a estrutura de um pedido detoken. O atributo opcionalContext contem

um URI que identifica a requisicao, e respostas subsequentes deverao referenciar essa mensa-

gem por esse URI. O elemento opcional<TokenType> identifica o tipo detokenrequerido por

meio de um URI. O elemento obrigatorio <RequestType> indica, por meio de um URI es-

pecifico da implementacao, qual o tipo de acao que esta sendo requisitada. A estrutura ainda

35

1 <wst:RequestSecurityToken Context="...">2 <wst:TokenType>...</wst:TokenType>3 <wst:RequestType>...</wst:RequestType>4 ...5 </wst:RequestSecurityToken>

Figura 16: Estrutura de um pedido detokenao STS (ANDERSON et al., 2005b).

permite que novos atributos e elementos filhos sejam adicionados ao elemento raiz do pedido,

como mecanismo de extensao.

1 <wst:RequestSecurityTokenResponse Context="...">2 <wst:TokenType>...</wst:TokenType>3 <wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>4 ...5 </wst:RequestSecurityTokenResponse>

Figura 17: Estrutura de uma resposta a um pedido detokenao STS (ANDERSON et al., 2005b).

A estutura da resposta a um pedido detoken(figura 17)e semelhantea do pedido. O

elemento raiz tambem possui um atributoContext, desta vez para referenciar o pedido ao qual

a resposta se refere (e obrigatorio se o pedido declarar uma URI), e um elemento<TokenType>.

A resposta contem ainda o proprio tokenrequisitado, no elemento opcional

<RequestedSecurityToken>. Este elemento pode conter uma referencia para umtoken, no

lugar do mesmo. A resposta tambem possui mecanismos de extensao por meio da definicao de

elementos e atributos adicionais.

A WS-Trustdefine ainda:

• diversos tipos de acoes para serem usados no elemento<RequestType>, e os elementos

adicionais que podem ser usados nos pedidos desses tipos;

• padroes de trocas de mensagens diferentes de pedido/resposta (como o padrao pedido/de-

safio/resposta);

• parametros adicionais que podem ser usados em pedidos e respostas ao STS.

4.4 WS-SECURECONVERSATION

A WS-Securityfornece meios para se proteger uma mensagem SOAP. Para muitos casose

suficiente que se cifre e/ou assine cada mensagem de uma interacao usando as chaves publica

36

e/ou privada das entidades envolvidas. Schneier (1996, p. 33) descreve os segeuintes problemas

no uso da criptografia assimetrica para cifrar mensagens:

• algoritmos de chave publica sao lentos. Criptografia simetricae cerca de 1000 vezes mais

rapida;

• sistemas criptograficos assimetricos sao vulneraveis a ataques de texto em claro escolhido

— onde o atacante escolhe o texto a ser cifrado pela chave — poise a chave publica a

usada para cifrar. Mesmo sendo impraticavel cifrar todos os textos planos possıveis para

descobrir o conteudo de uma mensagem,e possıvel — e pode ser perigoso — descobrir

que uma cifra nao provem de um texto em claro qualquer.

Outro problema da criptografia assimetrica, apontado por Weerawarana et al. (2005, p.

294), e que se muitas assinaturas forem geradas com uma mesma chave privada, para fins de

prover integridade, isso pode fornecer a um atacante informacao suficiente para revelar a chave.

A WS-SecureConversation(ANDERSON et al., 2005a) fornece uma solucao para esses

problemas. Essa especificacao define um modelo de autenticacao onde a privacidade e a in-

tegridade sao garantidas por meio de chaves simetricas geradas apenas para uso dentro de um

contexto especıfico. O contextoe definido por meio de um segredo que todos os servicosWeb

que fazem parte do contexto compartilham. Esse segredo pode ser uma chave simetrica, ou

entao um numero de onde chaves simetricas podem ser derivadas.

A WS-SecureConversationse constroi sobre o modelo de seguranca definido naWS-Se-

curity e WS-Trust. Assim, um contexto de segurancae representado por meio de umtoken

chamadoSecurity Context Token(SCT), que contem o segredo compartilhado e um URIunico

que serve para indicar aos servicosWebem qual contexto uma mensagem se insere. Um SCT

deve ser emitido por uma entidade confiavel, podendo essa ser um STS, ou um servicoWeb

participante do contexto.

4.5 WS-SECURITYPOLICY

O objetivo principal daWS-SecurityPolicy(DELLA-LIBERA et al., 2005)e prover um con-

junto inicial de assercoes — para serem usadas em conjunto com aWS-Policy— que descrevam

as caracterısticas de seguranca definidas naWS-Security, WS-Truste WS-SecureConversation.

Essas assercoes, no entanto, devem ser flexıveis o suficiente para serem usadas na definicao de

requisitos de seguranca de um modo geral.

37

A especificacao visa tambem, por meio de um modelo simples de assercoes, facilitar a

interseccao de polıticas, possibilitando delegar tal tarefa a uma implementacao que nao tenha

conhecimentos especıficos de seguranca, como algoritmos e parametros. O modelo de assercoes

definido naWS-SecurityPolicydivide as assercoes em grupos bem separados, a seguir (DELLA-

LIBERA et al., 2005):

• assercoes de protecao: indicam quais partes de uma mensagem estao sendo asseguradas;

• assercoes de condicao: expressam aspectos gerais ou pre-condicoes de seguraca;

• assercoes de amarracao de seguranca: declaram quais mecanismos de seguranca sao

usados para prover as caracterısticas de seguranca;

• assercoes detokensde suporte: os tipos e modelos detokensusados para prover garan-

tias adicionais;

• assercoesWS-Securitye WS-Trust: definem opcoes de referencias atokense de confi-

anca.

4.6 WS-FEDERATION

A especificacao WS-Federation(LOCKHART et al., 2006) estende os modelos de segu-

ranca daWS-Security, WS-Truste WS-Policydescrevendo como devem ser combinados a fim

de prover melhores mecanismos de mediacao de confianca, dentro de uma federacao ou entre

federacoes distintas.

A especificacao (LOCKHART et al., 2006) define federacao como:

uma colecao de domınios que estabeleceram um relacionamento produtor-consumidor onde um domınio pode prover autorizacao de acesso para um re-curso que ele gerencia baseado em uma identidade, e possivelmente atributosassociados, que sao afirmados em outro domınio.

O objetivo de uma federacao e o compartilhamento de informacoes, como identidades e

atributos, de acordo com uma certa polıtica. A polıtica dita como sera o compartilhamento,

pois as informacoes sao frequentemente pessoais e confidenciais. Para se estabelecer um con-

texto de federacao para um principal, ou sua identidadee universalmente aceita, ou precisa ser

convertida em identidades relevantes aos domınios federados (LOCKHART et al., 2006). No

ultimo caso,e comum que o mapeamento de identidades seja implementado por um STS (veja

secao 4.3), que funciona como um provedor de identidade (identity provider- STS/IdP).

38

Para que uma federacao seja formada,e necessario que as entidades envolvidas configurem

seus sistemas de modo a habilitar as operacoes federadas. Em uma federacao segundo aWS-

Federation, pode-se disponibilizar um conjunto de informacoes que facilita a inclusao de novos

parceirosa federacao. Essas informacoes sao chamadas de metadados da federacao, e sao

expostas em um formato XML padrao.

Figura 18: Processo de autenticacao por pseudonimos daWS-Federation(CAMARGO, 2006,apud (LOCKHART et al., 2006)).

As questoes de seguranca no modelo de federacoes surgem tanto no acesso aos recursos

disponibilizados pelas entidades federadas, quanto na protecao dos consumidores desses recur-

sos. Ha diversos casos em que um cliente nao deseja poder ser “rastreado”pelos provedores

de servicos, e em federacoes, o compartilhamento de informacoes de identidade pode facilitar

esse tipo de acao. Para evitar esse problema, aWS-Federationdefine um modelo de identidade

baseado empseudonimos. Um pseudonimoe um numero aleatorio gerado por umservico de

atributos/pseudonimos, quee usado no lugar da identidade do cliente. A figura 18 ilustra um

processo de autenticacao baseado em pseudonimos. Primeiramente o cliente se autentica no seu

provedor de identidade (passo 1a), e depois utiliza otokende identidade que recebeu para se

autenticar no STS/IdP do provedor de servicos (passo 2). Este havia registrado um pseudonimo

no servico de atributos/pseudonimos do cliente (passo 3) que o utiliza para se comunicar com

o provedor do recurso (passo 4). O provedor pode obter informacoes adicionais a respeito do

cliente no servico de atributos/pseudonimos de acordo com a sua identidade (validada no passo

1c).

39

REFERENCIAS

ANDERSON, S. et al.Web Services Secure Conversation Language (WS-SecureConversation). 2005. Disponıvel em: <http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf>. Acesso em: 28 jan 2007.

ANDERSON, S. et al.Web Services Trust Language (WS-Trust). 2005. Disponıvel em:<http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf>. Acesso em: 28 jan 2007.

BAJAJ, S. et al.Web Services Policy 1.2 - Attachment (WS-PolicyAttachment). 2006. W3CMember Submission. Disponıvel em: <http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment-20060425/>. Acesso em: 25 jan 2007.

BAJAJ, S. et al.Web Services Policy 1.2 - Framework (WS-Policy). 2006. W3C MemberSubmission. Disponıvel em: <http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/>. Acesso em: 25 jan 2007.

BARTEL, M. et al.XML-Signature Syntax and Processing. 2002. W3C Recommendation.Disponıvel em:<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>. Acesso em:24 jan 2007.

BOOTH, D. et al. (Ed.).Web Services Architecture. 2004. W3C Working Group Note.Disponıvel em:<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/>. Acesso em: 25jan 2007.

BOOTH, D.; LIU, C. K. (Ed.).Web Services Description Language (WSDL) Ver-sion 2.0 Part 0: Primer. 2006. W3C Candidate Recommendation. Disponıvel em:<http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327>. Acesso em: 22 jan 2007.

BOX, D. et al.Web Services Addressing (WS-Addressing). 2004. W3C Member Submission.Disponıvel em: <http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/>.Acesso em: 26 jan 2007.

BOYER, J. Canonical XML. 2001. W3C Recommendation. Disponıvel em:<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>. Acesso em: 24 jan 2007.

BRAY, T. et al. (Ed.).Namespaces in XML 1.1 (Second Edition). 2006. W3C Recommendation.Disponıvel em:<http://www.w3.org/TR/2006/REC-xml-names11-20060816>. Acesso em:24 jan 2006.

BRAY, T. et al. (Ed.).Extensible Markup Language (XML) 1.1 (Second Edition). 2006. W3CRecommendation. Disponıvel em:<http://www.w3.org/TR/2006/REC-xml11-20060816/>.Acesso em: 09 dez 2006.

CAMARGO, E. T.Transposicao de autenticacao e de autorizacao em arquiteturas orientadasa servicos atraves de identidades federadas. Dissertacao (Mestrado em Eng. Eletrica) —Universidade Federal de Santa Catarina, Florianopolis, 2006.

40

CARMINATI, B.; FERRARI, E.; HUNG, P. C. K. Web service composition: A securityperspective. In:Proceedings WIRI. [S.l.: s.n.], 2005. p. 248 –253.

CHARFI, A.; MEZINI, M. Using aspects for security engineering of web service compositions.In: Proceedings of the 2005 IEEE International Conference on Web Services. [S.l.: s.n.], 2005.I, p. 59–66.

CHINNICI, R. et al. (Ed.).Web Services Description Language (WSDL) Version 2.0Part 1: Core Language. 2006. W3C Candidate Recommendation. Disponıvel em:<http://www.w3.org/TR/2006/CR-wsdl20-20060327>. Acesso em: 22 jan 2007.

CLEMENT, L. et al. (Ed.).UDDI Version 3.0.2. 2004. OASIS Standard. Disponıvel em:<http://uddi.org/pubs/uddi-v3.0.2-20041019.htm>. Acesso em: 28 jan 2007.

COWAN, J.; TOBIN, R. (Ed.).XML Information Set (Second Edition). 2004. W3CRecommendation. Disponıvel em: <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>. Acesso em: 25 jan 2006.

DAEMEN, J.; RIJMEN, V.The design of Rijndael: AES - the Advanced Encryption Standard.[S.l.]: Springer-Verlag, 2002. 238 p.

DELLA-LIBERA, G. et al.Web Services Security Policy Language (WS-SecurityPolicy). 2005.Disponıvel em:<http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf>.Acesso em: 28 jan 2007.

DUERST, M.; SUIGNARD, M.Internationalized Resource Identifiers (IRIs). 2005. Requestfor Comments: 3987. Disponıvel em: <http://www.rfc-editor.org/rfc/rfc3987.txt>. Acessoem: 25 jan 2006.

ELGAMAL, T. A public key cryptsystem and a sygnature scheme based on discrete logarithms.In: IEEE Transactions on Information Theory. [s.n.], 1985. IT-31, n. 4, p. 469–472. Disponıvelem:<http://ieeexplore.ieee.org/iel5/18/22749/01057074.pdf>. Acesso em: 23 jan 2007.

ELLISON, C. et al.SPKI Certificate Theory. 1999. Internet Engineering Task Force Requestfor Coments 2693. Disponıvel em:<http://www.ietf.org/rfc/rfc2693.txt>. Acesso em: 23 jan2007.

FALLSIDE, D. C.; WALMSLEY, P. (Ed.).XML Schema Part 0: Primer Second Edition. 2004.W3C Recommendation. Disponıvel em:<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>. Acesso em: 24 jan 2006.

FIELDING, R. et al.Hypertext Transfer Protocol – HTTP/1.1. 1999. Disponıvel em:<ftp://ftp.isi.edu/in-notes/rfc2616.txt>. Acesso em: 09 dez 2006.

HOLLANDER, D.; SPERBERG-MCQUEEN, C. M.Results of W3C XML PlenaryBallot on relative URI References In namespace declarations. 2000. Disponıvel em:<http://www.w3.org/2000/09/xppa>. Acesso em: 25 jan 2006.

IMAMURA, T.; DILLAWAY, B.; SIMON, E. XML Encryption Syntax and Processing. 2002.W3C Recommendation. Disponıvel em: <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>. Acesso em: 24 jan 2007.

41

ISO/IEC.Information technology – Security techniques – Evaluation criteria for IT security– Part 1: Introduction and general model. 2. ed. Switzerland, sep 2005. Disponıvelem: <http://standards.iso.org/ittf/PubliclyAvailableStandards/c040612ISO IEC 15408-1 2005(E).zip>. Acesso em: 10 dez 2006.

ITU-T Recommendation X.509. 1993. Disponıvel em:<http://www.itu.int/rec/T-REC-X.509-199708-S/e>. Acesso em: 23 jan 2007.

LANDWEHR, C. E. Computer security.International Journal of Informa-tion Security, Springer-Verlag, v. 1, p. 3–13, jul 2001. Disponıvel em:<http://www.springerlink.com/content/nwk24a62ur0dfu9j/fulltext.pdf>. Acesso em:09 dez 2006.

LIGATTI, J.; BAUER, L.; WALKER, D. Edit automata: enforcement me-chanisms for run-time security policies.International Journal of Informa-tion Security, Springer-Verlag, v. 4, p. 2–16, oct 2004. Disponıvel em:<http://www.springerlink.com/content/ua8hglqrj2axkq1u/fulltext.pdf>. Acesso em: 10dez 2006.

LOCKHART, H. et al.Web Services Federation Language (WS-Federation) Version 1.1. 2006.Disponıvel em:<http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WS-Federation-V1-1B.pdf>. Acesso em: 03 fev 2007.

MELLO, E. R. D. et al. Seguranca em servicos web. In:Livro de Minicursos do VI SimposioBrasileiro de Seguranca da Informacao e de Sistemas Computacionais. Santos: SBC, 2006. p.1–48.

MILANEZ, J. Modelo de gerencia para o SPKI atraves do XKMS. Dissertacao (Mestrado emEng. Eletrica) — Universidade Federal de Santa Catarina, Florianopolis, 2005.

MITRA, N. (Ed.).SOAP Version 1.2 Part 0: Primer. 2003. W3C Recommendation. Disponıvelem:<http://www.w3.org/TR/2003/REC-soap12-part0-20030624>. Acesso em: 22 jan 2007.

MONZILLO, R. et al. (Ed.).Web Services Security: SAML Token Profile1.1. 2006. OASIS Standard Specification. Disponıvel em: <http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf>.Acesso em: 27 jan 2007.

NADALIN, A. et al. (Ed.). Web Services Security: Kerberos Token Profile1.1. 2006. OASIS Standard Specification. Disponıvel em: <http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf>.Acesso em: 27 jan 2007.

NADALIN, A. et al. (Ed.). Web Services Security: SOAP Message Security1.1. 2006. OASIS Standard Specification. Disponıvel em: <http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf>.Acesso em: 26 jan 2007.

NADALIN, A. et al. (Ed.). Web Services Security: UsernameToken Profile1.1. 2006. OASIS Standard Specification. Disponıvel em: <http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf>.Acesso em: 27 jan 2007.

42

NADALIN, A. et al. (Ed.). Web Services Security: X.509 Certificate Token Pro-file 1.1. 2006. OASIS Standard Specification. Disponıvel em: <http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf>. Acessoem: 27 jan 2007.

PELTZ, C. Web services orchestration and choreography.IEEE Computer, v. 36, n. 10, p.46–52, 2003.

PFLEEGER, C. P.Security in Computing. 2. ed. [S.l.]: Prentice Hall PTR, 1996.

RAGGETT, D.; HORS, A. L.; JACOBS, I. (Ed.).HTML 4.01 Specification. 1999. W3CRecommendation. Disponıvel em:<http://www.w3.org/TR/1999/REC-html401-19991224>.Acesso em: 24 jan 2006.

REAGLE, J. (Ed.).XML-Signature Requirements. 1999. W3C Working Draft. Disponıvel em:<http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014>. Acesso em: 24 jan2007.

REAGLE, J. (Ed.).XML Encryption Requirements. 2002. W3C Note. Disponıvel em:<http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304>. Acesso em: 25 jan2007.

RIVEST, R. L.; SHAMIR, A.; ADLEMAN, L. A method for obtaining digital signatures andpublic-key cryptosystems.Communications of the ACM, ACM Press, New York, NY, USA,v. 26, n. 1, p. 96–99, 1983. Disponıvel em: <http://doi.acm.org/10.1145/357980.358017>.Acesso em: 23 jan 2007.

SANDHU, R. S.; SAMARATI, P. Access control: principle and practice.Com-munications Magazine, IEEE, v. 32, n. 9, p. 40–48, sep 1994. Disponıvel em:<http://ieeexplore.ieee.org/iel1/35/7577/00312842.pdf>. Acesso em: 23 jan 2007.

SCHNEIER, B.Applied Cryptography Second Edition: protocols, algorithms, ans source in C.[S.l.]: John Willey & Sons, Inc., 1996.

SMID, M. E.; BRANSTAD, D. K. Data encryption standard: Past and future. In:Proceedings of the IEEE. [s.n.], 1988. v. 76, n. 5, p. 550–559. Disponıvel em:<http://ieeexplore.ieee.org/iel1/5/246/00004441.pdf>. Acesso em: 23 jan 2007.

SPECIFICATION for the Advanced Encryption Standard (AES). 2001. Fe-deral Information Processing Standards Publication 197. Disponıvel em:<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. Acesso em: 23 jan 2007.

STALLINGS, W.Network Security Essentials: Applications and Standards. Engelwood Cliffs,New Jersey: Prentice Hall, 2000.

WANGHAM, M. S. et al. Provendo garantias de segurancaa para formacao de organizacoesvirtuais.Gestao Avancada de Manufatura, v. 22, p. 75–84, 2005.

WEB Services Business Process Execution Language (WSBPEL). 2005.

WEB Services Choreography Description Language Version 1.0. 2005.

43

WEERAWARANA, S. et al.Web Services Plataform Architecture. Indiana: Prentice Hall,2005.

WIKIPEDIA. Service-oriented architecture. 2006. Disponıvel em:<http://en.wikipedia.org/wiki/Service-orientedarchitecture>. Acesso em: 05 dez2006.

Documents

DESENVOLVIMENTO DE UM PROTOTIPO PARA COMPOSIÇ´ … filedavi da silva boger¨ desenvolvimento de um prototipo para composiç´ ao˜ dinamica e segura de serviçosˆ web em sistemas