ARLINDO LUIS MARCON JUNIOR

GERENCIAMENTO DE POLTICAS DE CONTROLE

DE ACESSO FRACAMENTE ACOPLADO PARA

SERVIOS WEB

CURITIBA

2008

Dissertao apresentada ao Programa de Ps-

Graduao em Informtica da Pontifcia Universidade

Catlica do Paran como requisito parcial para

obteno do ttulo de Mestre em Informtica.

ii

iii

ARLINDO LUIS MARCON JUNIOR

GERENCIAMENTO DE POLTICAS DE CONTROLE

DE ACESSO FRACAMENTE ACOPLADO PARA

SERVIOS WEB

CURITIBA

2008

Dissertao apresentada ao Programa de Ps-

Graduao em Informtica da Pontifcia Universidade

Catlica do Paran como requisito parcial para

obteno do ttulo de Mestre em Informtica.

rea de Concentrao: Cincia da Computao

Orientador: Prof. Dr. Altair Olivo Santin

iv

Dados da Catalogao na Publicao

Pontifcia Universidade Catlica do Paran Sistema Integrado de Bibliotecas SIBI/PUCPR

Biblioteca Central

Marcon Junior, Arlindo Luis M321g Gerenciamento de polticas de controle de acesso fracamente acoplado 2008 para servios Web / Arlindo Luis Marcon Junior ; orientador, Altair Olivo Santin. 2008. xvii, 128 f. : il. ; 30 cm Dissertao (mestrado) Pontifcia Universidade Catlica do Paran, Curitiba, 2008 Bibliografia: f. 99-103 1. Redes de computao Medidas de segurana. 2. Servios da Web. 3. Computadores Controle de acesso. 4. Redes de computao Gerncia. I. Santin, Altair Olivo. II. Pontifcia Universidade Catlica do Paran. Programa de Ps-Graduao em Informtica. III. Ttulo. CDD 20. ed. 005.8

v

vi

A Deus Pai todo poderoso,

a Jesus Cristo seu nico filho, nosso Senhor,

a meus pais, Arlindo e Lidia, pela confiana e apoio.

vii

Agradecimentos

Agradeo a meu orientador, Dr. Altair Olivo Santin, pela pacincia, confiana, e

persistncia.

Aos membros da banca, Dr. Luiz e Dr. Rafael, obrigado pelas contribuies.

As professoras, Dra. Carla e Dra. Michelle, pelo apoio quando as procurei pedindo por

informaes sobre o mestrado.

Ao professor, Dr. Lau, por ter me auxiliado a entrar no mestrado da PUCPR.

Aos meus professores de graduao, Alexandre, Cirlei e Karen, o apoio deles foi

fundamental.

As amizades feitas durante estes anos, Altair, Cheila, Edson, Maicon, Marcelo,

Regivaldo, etc., obrigado pelo companheirismo e pelas grandes idias.

A meus amigos, que mesmo estando longe, me apoiaram e se lembraram de mim.

A minha tia, Hilda, sempre me ligando, e se preocupando comigo.

E principalmente, agradecer a meu pai e minha me, Arlindo Luiz Marcon e Lidia

Ortigara Marcon, por terem me apoiado nesta aventura do conhecimento, sem eles, nada disso

teria sido possvel.

viii

Resumo

Atualmente, a troca de informaes atravs da Internet se tornou no somente

possvel, mas uma necessidade, as empresas precisam interagir com um nmero cada vez

maior de parceiros de negcio e consumidores. Em tais cenrios, mtodos tradicionais

utilizados para gerenciar direitos, identidades, e impor regras de controle de acesso no so

mais suficientes. As entidades de controle precisam confiar umas nas outras para trocar

informaes sensveis e compartilhar recursos. Interaes deste tipo so complexas, visto que

as entidades, geralmente, fazem parte de diferentes domnios de segurana ou no possuem

relacionamentos confiveis pr-estabelecidos. Cenrios como estes exigem a padronizao da

troca de informaes, gerenciamento de direitos e estabelecimento de confiana para lidar

com a heterogeneidade das plataformas. Um dos objetivos do presente trabalho fazer uso de

certificados de autorizao para transportar os atributos que sero utilizados em mecanismos

de autenticao e autorizao distribudos. Unindo-se os certificados de autorizao a uma

arquitetura de controle de polticas baseada no modelo de configurao (provisionamento), se

diminui a dependncia existente entre as entidades que aplicam as polticas de controle de

acesso no ambiente distribudo (corporativo, por exemplo). O desenvolvimento do modelo

proposto permite a gerncia descentralizada das polticas de controle de acesso dispersas pelo

ambiente distribudo, possibilitando a gerao automatizada de polticas de granularidade fina

no ambiente local das filiais da corporao. A abordagem utilizada no permite que as regras

de polticas sejam violadas, pois os direitos atribudos localmente, nas filiais, so derivados

dos direitos definidos em nvel corporativo. As permisses de acesso e a gerao

automatizada de polticas locais so derivadas de certificados de autorizao providos por

uma infra-estrutura de chave pblica desprovida de Autoridade Certificadora. Os certificados

de autorizao fornecem informaes suficientes para gerar uma credencial de autorizao e

uma nova poltica. A credencial de autorizao utilizada pelo guardio do recurso para

liberar, ou bloquear o acesso do sujeito ao recurso oferecido pela filial. Toda nova poltica

enviada a um repositrio de poltica corporativo, utilizado para preservar a viso

administrativa unificada do ambiente distribudo de controle de acesso. Uma cpia da nova

poltica e enviada para a respectiva filial onde est instanciado o mecanismo de controle de

acesso, favorecendo assim a autonomia local das filiais. Esta atualizao no repositrio da

ix

filial mantm o mesmo consistente com o repositrio de polticas corporativo. A abordagem

proposta concede autonomia s filiais no processo de avaliao de polticas, favorecendo a

interoperabilidade, flexibilidade, e escalabilidade. Propriedades estas almejadas pela

Arquitetura Orientada a Servio e pelos Servios Web. A presente proposta diminui

significativamente a interveno do administrador corporativo, sem que o mesmo perca o

controle administrativo sobre as polticas de controle de acesso aplicadas no ambiente

distribudo.

Palavras-Chave: Controle de Acesso, Provisionamento de Polticas, Certificados de

Autorizao, Servios Web.

x

Abstract

Nowadays, the information exchange through the Internet has become not only possible, it is

a need. The enterprises need to interact with an ever growing number of partners and

consumers. In such scenarios, traditional methods for managing rights and identities, and

enforcement of access control rules are not enough. The controlling entities need to trust in

each other to exchange sensitive information and share resources. Interactions like this are

complex, due to the fact that both entities, commonly, belong to different security domains, or

dont have previously established trust relationships. Scenarios like this demand a

standardization of information exchange, rights management and trust establishment to

support platform heterogeneity. One of this work's goals is to make use authorization

certificates to convey authentication and authorization attributes that will be used by

distributed authentication and authorization mechanisms. By incorporating authorization

certificates with an access control architecture based on the provisioning model, we can

reduce the dependence present amongst the entities that enforce the access control policies in

a distributed environment (e.g.: corporate environment). The implementation of the proposed

model allows for the decentralized access control policies management in distributed

environment, enabling automated generation of fined grained policies in the local

environment of each corporation branch. The employed approach does not allow violation of

the policies' rules, as the rights in each branch are derived from the rights defined in the

corporate level. Access rights and automated generation of local policies derive from

authorization certificates provided by a serverless public key infrastructure. The authorization

certificates provide enough data to generate an authorization credential and a new policy. The

authorization credential is used by the resource guardian to allow or deny the subject's access

to the resource provided by the local branch. Every new policy is sent the corporative policy

repository, employed to preserve a keep an unified administrative view of the distributed

access control environment. One copy of the new policy is sent to the enterprise branch where

the access control mechanism is instantiated, favoring local autonomy on the branches. This

updates on the branch's repository keeps same consistent with the corporations policy. The

proposed approach gives autonomy to the branches on the policies evaluation process,

favoring interoperability, flexibility, and scalability. Properties which are aimed by Service

xi

Oriented Architectures and Web Services. The present proposal significantly reduces the

intervention of the corporative administrator, without him loosing administrative control over

the access control policies applied to the distributed environment.

Keywords: Access Control, Policy Provisioning, Authorization Certificates, Web Services.

xii

Lista de Figuras

FIGURA 2.1: FRAGMENTO DE UM DOCUMENTO XML.............................................................................................. 14 FIGURA 2.2: MENSAGEM SOAP.............................................................................................................................. 15 FIGURA 2.3: PRINCIPAIS ENTIDADES QUE COMPEM A ARQUITETURA DOS SERVIOS WEB.................................... 17 FIGURA 3.1: DOCUMENTO XML EM TEXTO CLARO................................................................................................. 22 FIGURA 3.2: DOCUMENTO XML CIFRADO .............................................................................................................. 22 FIGURA 3.3: ARQUITETURA DE SEGURANA DOS SERVIOS WEB........................................................................... 25 FIGURA 3.4: PEDIDO SPML ENVIADO AO SERVIO DE PROVISIONAMENTO............................................................. 32 FIGURA 3.5: RESPOSTA SPML RETORNADA AO SOLICITANTE................................................................................. 33 FIGURA 4.1: CERTIFICADO DE AUTORIZAO SPKI/SDSI CODIFICADO EM S-EXPRESSION .................................... 37 FIGURA 4.2: FLUXO DE AUTORIZAO BASEADO EM DELEGAO ........................................................................ 38 FIGURA 4.3: MODOS DE OPERAO PUSH E PULL................................................................................................... 40 FIGURA 4.4: MODELO OUTSOURCING ...................................................................................................................... 42 FIGURA 4.5: MODELO PROVISIONING ...................................................................................................................... 43 FIGURA 4.6: MODELO DO FLUXO DE DADOS COM AS PRINCIPAIS ENTIDADES DA XACML ..................................... 49 FIGURA 5.1: ARQUITETURA DO MODELO................................................................................................................. 52 FIGURA 5.2: PROCEDIMENTO DE CONTROLE DE ACESSO EFETUADO SOBRE O RECURSO [2] .................................... 54 FIGURA 5.3: MODELO DE TRANSPOSIO PROPOSTO [3]......................................................................................... 57 FIGURA 5.4: CENRIO DO USO DE UM SERVIO QUE CRUZA DOMNIOS ................................................................... 64 FIGURA 5.5: COMPARAO ENTRE IBAC E ABAC................................................................................................. 65 FIGURA 5.6: ARQUITETURA DO MODELO WS-ABAC ............................................................................................. 70 FIGURA 6.1: INTERAO ENTRE AS ENTIDADES DO MODELO PARA AOS ................................................................ 74 FIGURA 6.2: INTERAO ENTRE AS ENTIDADES DO MODELO COM SERVIOS WEB ................................................. 77 FIGURA 6.3: PROTOCOLOS E ESPECIFICAES UTILIZADAS NA ARQUITETURA DO PROTTIPO ................................ 79 FIGURA 7.1: PSEUDOCDIGO - PEP RECEBE A SOLICITAO .................................................................................. 84 FIGURA 7.2: PSEUDOCDIGO - VALIDAR A CADEIA DE CERTIFICADOS SPKI/SDSI NO GCT2 ................................. 84 FIGURA 7.3: PSEUDOCDIGO - CRIAR POLTICA XACML NO GCT2 ....................................................................... 85 FIGURA 7.4: PSEUDOCDIGO - CRIAR ASSERO SAML NO GCT2 ........................................................................ 85 FIGURA 7.5: ASSERO SAML GERADA A PARTIR DA CADEIA REDUZIDA DE CERTIFICADOS SPKI/SDSI.............. 86 FIGURA 7.6: POLTICA XACML GERADA A PARTIR DA CADEIA REDUZIDA DE CERTIFICADOS SPKI/SDSI............. 87 FIGURA 7.7: INTERAO ENTRE AS ENTIDADES DO MODELO COM SERVIOS WEB ................................................. 89 FIGURA 7.8: TAMANHO DA MENSAGEM EM CADA MODELO..................................................................................... 90 FIGURA 7.9: TEMPO TOTAL DE RESPOSTA PARA O CLIENTE EM CADA MODELO....................................................... 90 FIGURA 7.10: PERCENTAGEM DE TEMPO GASTA EM CADA ENTIDADE DOS MODELOS.............................................. 92 FIGURA 7.11: QUANTIDADE DE PRINCIPALS ATENDIDOS EM CADA MODELO............................................................ 93 FIGURA 7.12: PROVISIONAMENTO DE POLTICAS PDP PARA LPAP...................................................................... 95

xiii

Lista de Abreviaturas

Abreviatura Acrnimo por extenso Significado

ACL Access Control List Lista de Controle de Acesso

AOS --- Arquitetura Orientada a Servio

API Application Program Interface Interface para Programao de Aplicativos

AS Authentication Service Servio de Autenticao

ASCII American Standard Code for Information Interchange Cdigo Padro Americano para

Intercmbio de Informaes

CA Certificate Authority Autoridade Certificadora

COPS Common Open Policy Service Servio de Poltica Aberto

COPS-PR COPS for Policy Provisioning COPS para Provisionamento de Poltica

CORBA Common Object Request Broker Architecture Arquitetura Comum para Agente de

Requisio de Objetos

CRC Certificate Result Certificates Certificado Resultado dos Certificados

CRL Certificate Revocation Lists Lista de Revogao de Certificados

DTD Document Type Definition Definio do Tipo do Documento

HTTP Hypertext Transport Protocol Protocolo de Transporte de Hipertexto

ICP --- Infra-Estrutura de Chave Pblica

IdP Identity Provider Provedor de Identidade

IETF Internet Engineering Task Force Fora Tarefa de Engenharia Internet

IP Internet Protocol Protocolo Internet

IPSec Internet Protocol Security Protocolo Internet Seguro

JDK Java Development Kit Ferramentas para Desenvolvimento de Programas na Linguagem Java

xiv

OASIS Organization for the

Advancement of Structured Information Standards

Organizao para o Avano de Padres de Informao Estruturados

PAP Policy Administration Point Ponto de Administrao de Poltica

PCIM Policy Core Information Model Modelo Central de Informao de Poltica

PDP Policy Decision Point Ponto de Deciso de Polticas

PEP Policy Enforcement Point Ponto de Aplicao de Polticas

PIB Policy Information Base Base de Informao de Poltica

PIP Policy Information Point Ponto de Informao de Polticas

PKI Public Key Infrastructure Infra-estrutura de Chave Pblica

SAML Security Assertion Markup Language Linguagem de Marcao para

Asseres de Segurana

SDSI Simple Distributed Security Infrastructure Infra-estrutura de Segurana

Distribuda Simples

SMTP Simple Mail Transport Protocol Protocolo Simples de Transporte de Correspondncia

SOA Service Oriented Architecture Arquitetura Orientada a Servio

SOAP Simple Object Access Protocol Protocolo Simples de Acesso a Objetos

SP Service Provider Provedor de Servio

SPKI Simple Public-Key Infrastructure Infra-estrutura de Chave Pblica Simples

SPML Service Provisioning Markup Language Linguagem de Marcao para

Configurao de Servios

SSL Secure Sockets Layer Camada de Soquetes Segura

SSO Single Sign-On Inscrio nica

STS Security Token Service Servio de Credenciais Seguras

TCP Transmission Control Protocol Protocolo de Controle de Transmisso

TGS Ticket Granting Service Servio de Concesso de Bilhete

TGT Ticket Granting Ticket Bilhete para Concesso de Bilhete

xv

TLS Transport Layer Security Segurana na Camada de Transporte

TTP Trusted Third Party Terceira Parte Confivel

UBR UDDI Business Registry Registro de Negcios UDDI

UDDI Universal Description Discovery and Integration Descrio, Descoberta e Integrao

Universais

URI Uniform Resource Identifiers Identificador de Recursos Uniforme

URL Uniform Resource Locators Localizador de Recursos Uniforme

UTC Universal Time Coordinated Tempo Universal Coordenado

VPN Virtual Private Network Rede Privada Virtual

W3C World Wide Web Consortium Consrcio da World Wide Web

WS Web Services Servios Web

WSDL Web Services Description Language Linguagem de Descrio de Servios

Web

WS-I Web Services Interoperability Organization Organizao para Interoperabilidade

dos Servios Web

XACML eXtensible Access Control Markup Language Linguagem de Marcao Extensvel

para Controle de Acesso

X-KISS XML Key Information Service Specification Especificao XML para Servio de

Informao de Chaves

XKMS XML Key Management Specification Especificao para Gerenciamento

de Chaves XML

X-KRSS XML Key Registration Service Specification Especificao XML para Servio de

Registro de Chaves

XML Extensible Markup Language Linguagem de Marcao Extensvel

xvi

Sumrio

CAPTULO 1.......................................................................................................................................................... 1

1. INTRODUO............................................................................................................................................. 1

1.1 CONTEXTUALIZAO .......................................................................................................................... 1 1.2 OBJETIVOS........................................................................................................................................... 7 1.3 ORGANIZAO .................................................................................................................................... 9

CAPTULO 2........................................................................................................................................................ 11

2. ARQUITETURA ORIENTADA A SERVIO E SERVIOS WEB .................................................... 11

2.1 INTRODUO..................................................................................................................................... 11 2.2 ARQUITETURA ORIENTADA A SERVIO (AOS) ................................................................................. 11 2.3 LINGUAGEM DE MARCAO EXTENSVEL (XML) ............................................................................ 13 2.4 PROTOCOLO SIMPLES DE ACESSO A OBJETOS (SOAP)...................................................................... 15 2.5 SERVIOS WEB.................................................................................................................................. 16

2.5.1 Linguagem para Descrio dos Servios Web (WSDL)..................................................... 18 2.6 CONCLUSO ...................................................................................................................................... 19

CAPTULO 3........................................................................................................................................................ 20

3. PADRONIZAO PARA XML E SERVIOS WEB ........................................................................... 20

3.1 INTRODUO..................................................................................................................................... 20 3.2 PADRES DE SEGURANA PARA XML .............................................................................................. 21

3.2.1 XML Encryption ................................................................................................................. 21 3.2.2 XML Signature ................................................................................................................... 23 3.2.3 XML Canonical .................................................................................................................. 24

3.3 PADRES PARA SERVIOS WEB......................................................................................................... 24 3.3.1 Web Service Security: SOAP Message Security (WS-Security) ......................................... 25 3.3.2 WS-Trust............................................................................................................................. 26 3.3.3 Web Services Policy (WS-Policy)....................................................................................... 29 3.3.4 Especificao para Gerenciamento de Chaves XML (XKMS)........................................... 30 3.3.5 Linguagem de Marcao para Configurao de Servios (SPML) ................................... 30

3.4 CONCLUSO ...................................................................................................................................... 33

CAPTULO 4........................................................................................................................................................ 34

4. ARQUITETURAS DE CONTROLE DE ACESSO E LINGUAGENS PARA APLICAO DE POLTICAS ................................................................................................................................................ 34

xvii

4.1 INTRODUO......................................................................................................................................34 4.2 MODELO SPKI/SDSI .........................................................................................................................35

4.2.1 Certificado de Nomes..........................................................................................................35 4.2.2 Certificado de Autorizao .................................................................................................36 4.2.3 Fluxo de Autorizao Baseado em Delegao ...................................................................38 4.2.4 Certificado Resultado dos Certificados ..............................................................................39

4.3 MODOS DE OPERAO PUSH E PULL ..................................................................................................39 4.4 MODELO DE INFORMAO DE POLTICAS (PCIM) .............................................................................40

4.4.1 Modelo Outsourcing (terceirizao)...................................................................................41 4.4.2 Modelo Provisioning (configurao)..................................................................................42

4.5 LINGUAGEM DE MARCAO PARA ASSERES DE SEGURANA (SAML).........................................44 4.6 LINGUAGEM DE MARCAO PARA CONTROLE DE ACESSO (XACML)..............................................45 4.7 CONCLUSO.......................................................................................................................................49

CAPTULO 5 ........................................................................................................................................................51

5. CONTROLE DE ACESSO EM ARQUITETURAS ORIENTADAS A SERVIO .............................51

5.1 INTRODUO......................................................................................................................................51 5.2 MEDIAO DE CONFIANA ATRAVS DE SERVIOS WEB ..................................................................51 5.3 TRANSPOSIO DE AUTENTICAO EM AOS ATRAVS DE IDENTIDADES FEDERADAS.....................55 5.4 MODELO DE CONTROLE DE ACESSO SENSVEL AO CONTEXTO PARA SERVIOS WEB .......................59 5.5 CONTROLE DE ACESSO BASEADO EM AUTORIZAO PARA ARQUITETURA ORIENTADA A SERVIO.62 5.6 MODELO DE CONTROLE DE ACESSO BASEADO EM ATRIBUTOS PARA SERVIOS WEB ......................67 5.7 CONCLUSO.......................................................................................................................................70

CAPTULO 6 ........................................................................................................................................................72

6. GERENCIAMENTO DE POLTICAS DE CONTROLE DE ACESSO FRACAMENTE ACOPLADO PARA SERVIOS WEB ....................................................................................................72

6.1 INTRODUO......................................................................................................................................72 6.2 MODELO PARA AOS ..........................................................................................................................73 6.3 MODELO PARA SERVIOS WEB..........................................................................................................76 6.4 DINMICA DO PROTTIPO EM AMBIENTE DE SERVIOS WEB............................................................78 6.5 CONCLUSO.......................................................................................................................................80

CAPTULO 7 ........................................................................................................................................................82

7. IMPLEMENTAO E AVALIAO DO PROTTIPO.....................................................................82

7.1 INTRODUO......................................................................................................................................82 7.2 TECNOLOGIAS ....................................................................................................................................82 7.3 IMPLEMENTAO ...............................................................................................................................83 7.4 AVALIAO DO PROTTIPO ...............................................................................................................88

xviii

7.5 CONCLUSO ...................................................................................................................................... 96

CAPTULO 8........................................................................................................................................................ 97

8. CONCLUSO............................................................................................................................................. 97

8.1 TRABALHOS FUTUROS....................................................................................................................... 98

REFERNCIAS BIBLIOGRFICAS ............................................................................................................... 99

APNDICE A ..................................................................................................................................................... 104

9. ARQUITETURA ORIENTADA A SERVIO E SERVIOS WEB .................................................. 104

A.1. MODELO CONCEITUAL DA AOS .......................................................................................................... 104 A.2. ARQUITETURA GERAL DOS SERVIOS WEB......................................................................................... 105

A.2.1. Modelo Orientado a Mensagem (MOM).............................................................................. 105 A.2.2 Modelo Orientado a Servio (SOM) ..................................................................................... 106 A.2.3 Modelo Orientado a Recurso (ROM).................................................................................... 107 A.2.4. O Modelo de Poltica (PM).................................................................................................. 107

A.3. DESCRIO, DESCOBERTA E INTEGRAO UNIVERSAIS (UDDI) ........................................................ 108 A.4. ESPECIFICAES ADICIONAIS PARA SERVIOS WEB ........................................................................... 110 A.5. CASO DE USO COM A WS-TRUST......................................................................................................... 111 A.6. WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION)............................................................. 112 A.7. CASO DE USO COM A WS-POLICY ....................................................................................................... 116 A.8. SERVIOS DISPONIBILIZADOS PELA ESPECIFICAO XKMS............................................................... 117 A.9. CASO DE USO COM A SPML ................................................................................................................ 118

APNDICE B ..................................................................................................................................................... 121

10. MODELOS DE SEGURANA E CONTROLE DE POLTICAS...................................................... 121

B.1. SPKI/SDSI .......................................................................................................................................... 121 B.1.1. Dinmica de Acesso SPKI/SDSI .......................................................................................... 121 B.1.2. Threshold Subjects - TS........................................................................................................ 122 B.1.3. S-Expressions (Sexps) .......................................................................................................... 123 B.1.4. Garantia do Certificado ....................................................................................................... 123 B.1.5. Lista de Controle de Acesso em SPKI/SDSI......................................................................... 123

B.2. ACORDO EM NVEL DE SERVIO (SLA) ............................................................................................... 124 B.3. CASO DE USO COM O MODELO OUTSOURCING ..................................................................................... 124 B.4. COMMON OPEN POLICY SERVICE FOR POLICY PROVISIONING (COPS-PR) ......................................... 126 B.5. SECURITY ASSERTION MARKUP LANGUAGE (SAML)......................................................................... 127

B.5.1. SAML Single Sign On........................................................................................................... 127 B.5.2. Assero de Autenticao SAML ......................................................................................... 127

Captulo 1

1. Introduo

O uso da Internet tem se intensificado significativamente, se tornando uma das

necessidades nos dias atuais. Usurios tm utilizado cada vez mais a Internet para realizar

tarefas cotidianas, como por exemplo, efetuar transaes bancrias em Bancos via Internet

(i.e.: Internet Banking), realizar a compra e venda online em sites que comercializam produtos

(comodidade), manter contato com outras pessoas fazendo uso de programas de mensagem

instantnea, entre outras atividades dirias.

O aumento da utilidade e da usabilidade da Internet tem sido referenciado como Web

2.0 [1]. A rede de informaes, seja em formato texto (hipertexto) ou multimdia (e.g.:

YouTube), revitalizou a Internet em termos de utilidade e usabilidade. A Arquitetura

Orientada a Servio (AOS) parte integrante da Web 2.0, tendo nos Servios Web (Web

Services - WS) uma de suas implementaes de maior aceitao e que mais tem se difundido.

Neste captulo explanaremos a contextualizao do problema e os principais objetivos

que nos motivaram a desenvolver o presente trabalho.

1.1 Contextualizao

A ampla cobertura das redes de comunicao est fazendo corporaes distribudas

geograficamente vislumbrarem a possibilidade de integrar seus sistemas, configurar os

mesmos, ou prestar servios a clientes na Internet.

Com a globalizao, cada organizao que fornece servios pode contratar, ou se

associar a outras empresas especializadas em determinadas atividades, realizando assim

servios para os quais, sozinha, no possuiria competncia tcnica para o provimento. Isto

aumenta abrangncia da rea de atuao, fornecendo um nico servio composto pela

2

integrao de vrias empresas altamente especializadas em determinadas reas.

A terceirizao de servios de maneira permanente ou temporria causa a interao

entre clientes, grupos de trabalho, corporaes e suas filiais, e tambm a necessidade de

acesso recursos localizados em diferentes domnios (e.g.: parceiros da corporao). Isto

exige um modelo de controle de acesso que aceite opes de configurao de maneira pr-

estabelecida e dinmica.

Em meios de interao como os supracitados, a aplicao de polticas pr-

estabelecidas e dinmicas, sem a interveno do administrador local (i.e.: administrador da

filial ou parceira), facilitaria o gerenciamento do ambiente de controle de acesso distribudo.

Em condies ideais, o principal1 que deseja acessar certo recurso, mesmo no estando

presente nas polticas locais da filial, poderia simplesmente apresentar uma credencial para o

guardio do recurso e ter o acesso autorizado.

Realizar a troca de informaes de maneira padronizada e segura, e controlar o acesso

a recursos expostos na Internet em uma corporao com sistemas distribudos e heterogneos,

no uma atividade trivial. Confiar a escrita das polticas de controle de acesso de fina

granularidade unicamente a administradores de segurana em nvel corporativo, torna o

processo demorado, propenso a erros e talvez at invivel. Semelhantemente, confiar a escrita

das polticas de controle de acesso para os administradores das filiais no garante que as

polticas corporativas sero corretamente aplicadas.

Levando-se em considerao o crescente nmero de recursos, principals e a

diversidade de plataformas existentes, o procedimento de escrita e administrao de polticas

se torna cada vez mais trabalhoso.

Sistemas de controle de acesso tradicionais aplicados na maioria das arquiteturas so

centralizados. Esta abordagem, apesar de tornar o sistema mais facilmente gerencivel,

concentra os processos de administrao de polticas, autenticao e autorizao em um nico

ponto. Com isto, o sistema se torna pouco flexvel e escalvel, gerando o ponto nico de

falhas, e restringindo o principal de um domnio no acesso a recursos expostos por outros

domnios. Todas as credenciais, de todos os principals, devem estar devidamente cadastradas

1 Principal um termo genrico utilizado para designar qualquer entidade (e.g.: humano ou programa)

que est solicitando acesso a um recurso ou servio.

3

e atualizadas nos demais domnios detentores do recurso almejado.

O procedimento de sincronizao e atualizao de informaes interdomnios exige

um tempo considervel, sendo propenso a erros manuais. Contas de usurios rfos que

deveriam ter sido excludas ou canceladas podem permanecer no sistema, fornecendo acesso

para quem no tem mais direito ao mesmo. Problema comum e facilmente encontrado em

sistemas distribudos de controle de acesso.

Alm dos mecanismos de autenticao e autorizao inflexveis e centralizados usados

em Arquiteturas Orientadas a Servio, alguns destes estabelecem forte acoplamento entre os

principals e os provedores de servio.

O alto acoplamento pode ser descrito pela excessiva troca de mensagens entre as

entidades do sistema, a dependncia de entidades externas ao domnio do provedor de servio,

ou a necessidade de se compartilhar um mecanismo de confiana comum (uma Trusted Third

Party como servio de autenticao, por exemplo) entre as partes (e.g.: clientes e provedores).

Gera-se tambm, muitas vezes, a centralizao dos mecanismos que realizam os processos de

distribuio de credenciais de autenticao e autorizao em um nico ponto.

As caractersticas supracitadas ajudam a tornar os sistemas mais vulnerveis e

susceptveis a ataques, os quais podem levar a negao de servio ou a parada do sistema que

dependa de tal servio.

A Arquitetura Orientada a Servio (AOS) e os Servios Web (Web Services - WS) tm

mostrado boa aceitao e rpida padronizao, auxiliando na resoluo de algumas limitaes

no abordadas por outros padres existentes. O uso de interfaces padronizadas utilizadas para

descrever as capacidades de um servio, facilita a localizao e a interao com os seus

prestadores. A AOS oferece facilidades para conectar os sistemas da matriz com as filiais, ou

implementar interaes entre parceiros de negcios atravs da troca de mensagens

padronizadas, realizadas entre os sistemas que compem tais ambientes.

Atualmente h a necessidade de se autenticar, autorizar e confiar no principal que est

fazendo uso dos servios expostos na web por um determinado provedor. Somente

autenticao e autorizao no so mais suficientes para prover a segurana necessria,

preciso conhecer o domnio de origem do principal e se o mesmo uma entidade confivel.

Porm, introduzir o conceito confiana para sistemas computacionais no uma tarefa

simples. A maioria das infra-estruturas e modelos de autenticao e autorizao propostos na

literatura, e usando AOS, abordam de forma genrica o conceito de confiana. Por outro lado,

4

criam sistemas fortemente acoplados (i.e.: exigindo o uso de mecanismos de autenticao e

autorizao especficos ou fazendo uso de um grande nmero de troca de mensagens) para

tentar suprir o seu uso e a sua complexidade de implementao.

O forte acoplamento est concentrado, principalmente, entre as entidades de segurana

do sistema e entre os mecanismos que realizam a avaliao e aplicao das polticas de

controle de acesso, como implementado em [2] e [3], por exemplo. O ideal, que a

arquitetura oferea o mximo de flexibilidade, exigindo o mnimo de dependncia de um

mecanismo ou servio especfico.

A flexibilidade e a mnima dependncia devem ser utilizadas sem afetar a avaliao

correta do sistema de controle de acesso. Ou seja, no autorizar principals que no possuem

direitos de acesso ao recurso. O trabalho apresentado em [4] sugere uma abordagem

interessante, porm, se mantm em nvel de modelo, carecendo de provas mais concretas para

mostrar sua aplicabilidade em ambientes reais.

A grande maioria dos trabalhos disponveis na literatura cientfica aborda a AOS de

maneira incompleta, necessitando de estudos mais aprofundados sobre aspectos como a

aplicao de polticas distribudas e de granularidade fina, sistemas distribudos de controle de

acesso, estabelecimento dos relacionamentos de confiana, gerenciamento das contas dos

principals, entre outros. Geralmente, os mesmos esto preocupados com algumas

especificidades em um determinado objetivo da AOS, expondo modelos que vo contra os

princpios de baixo acoplamento almejados pela Arquitetura Orientada a Servio.

A adoo de uma infra-estrutura de chave pblica flexvel auxiliaria na atividade de

gesto de polticas para ambientes mais dinmicos, sem exigir uma infra-estrutura de

servidores de autenticao especficos, diminuindo a necessidade de interveno do

administrador. Adicionalmente as polticas de autorizao podem ficar dispersas pelo

ambiente distribudo. Processos de assinatura e cifragem diminuem as possibilidades de

alteraes indevidas, garantindo a credibilidade dos certificados de autorizao emitidos por

tal infra-estrutura.

A administrao descentralizada de direitos baseada em uma infra-estrutura de chaves

pblicas flexvel permite que o administrador corporativo delegue direitos ao administrador

local (i.e.: administrador das filiais). Esta abordagem permite que o administrador corporativo

no corra o risco de no perceber o administrador local violar as polticas corporativas. Ou

seja, no possvel ao administrador local atribuir sua discrio algum direito que no seja

5

derivado daqueles delegados pelo administrador em nvel corporativo.

O custo da administrao humana de polticas corporativas bastante significativo,

pois imprescindvel que cada regra de poltica (i.e.: poltica de fina granularidade) seja

criada manualmente. necessrio um processo automatizado e que utilize mecanismos

padronizados, visando facilitar a administrao das polticas.

Atravs dos certificados de autorizao e da concesso de direitos possvel gerar

novas polticas com fina granularidade no domnio de cada filial. As novas polticas servem

para atualizar o repositrio de polticas corporativo, preservando a viso administrativa

unificada do ambiente de controle de acesso distribudo. As polticas recebidas pela

administrao corporativa so usadas para atualizar, automaticamente, os repositrios de

polticas dos respectivos provedores de servios instanciados nas filiais.

A gerao automatizada de polticas de fina granularidade feita de maneira segura,

pois a poltica extrada de parmetros codificados nos certificados de autorizao. Com esta

abordagem, os administradores (em nvel corporativo ou nas filiais) esto livres do encargo de

escrever novas polticas especficas para todo sujeito e respectivo recurso.

Este esquema ajuda manter a viso unificada das polticas administrativas aplicadas

em ambientes distribudos tal como em Arquiteturas Orientadas a Servio. Prtica esta que

seria difcil de obter com as abordagens tradicionais. No esquema proposto neste trabalho, se

diminu consideravelmente a dependncia de entidades internas e ou externas ao domnio do

provedor, caracterstica esta que seria inevitvel com as abordagens tradicionais.

Em ambientes como a Internet, onde a conexo entre as entidades (e.g.: monitor de

referncia e guardio) no pode ser totalmente garantida (i.e.: servio sempre online) sem

gastos adicionais com infra-estrutura (i.e.: garantia fornecida pela prestadora de servios de

telecomunicao), o modelo de avaliao de polticas baseado em pr-configurao torna-se

indispensvel.

A pr-configurao pode ser descrita pelo fornecimento (i.e.: provisionamento) de

configuraes para um determinado sistema, antes de este executar alguma tarefa.

O modelo de provisionamento pode ser usado para configurar os mecanismos que

realizam a aplicao das polticas distribudas, ajudando a diminuir o acoplamento (e.g.: troca

de mensagens) entre as entidades de controle presentes no domnio do provedor, e as

fornecedoras de informaes sobre os principals instanciadas no domnio do cliente.

A utilizao do modelo de provisionamento reduz o overhead de comunicao entre o

6

monitor de referncia corporativo e o guardio no processo de tomada de deciso sobre

solicitaes de acesso. A implementao deste modelo permite que os domnios dos

provedores de servios (i.e.: filiais da corporao) continuem atendendo solicitaes de acesso

mesmo na indisponibilidade do monitor de referncia em nvel corporativo, por exemplo.

O maior nmero de mensagens trocadas entre as entidades que decidem e impem as

polticas, conseqentemente, gera maior overhead no sistema e maior trfego de informaes

sobre a rede. Caractersticas estas que colaboram para o aumento do tempo de resposta para o

principal (i.e.: cliente) durante a concretizao de uma solicitao feita aos provedores de

servio. Estas peculiaridades contribuem para tornar os sistemas pouco flexveis e escalveis.

O ganho no tempo de resposta proporcionado pelo modelo de provisionamento

diminuiu a espera para que o principal obtenha acesso ao recurso, pois o modelo, da maneira

como foi implementado, no depende de entidades externas ao domnio do provedor, filial da

corporao. A implementao de sistemas de controle de acesso em Servios Web, baseados

no paradigma de provisionamento, sequer foi discutida por algum trabalho da literatura.

O tema atual e relevante, sendo que isto facilmente observado quando verificamos

as entidades envolvidas na criao de normas relativas ao mesmo: IETF (Internet Engineering

Task Force), OASIS (Organization for the Advancement of Structured Information

Standards), WS-I (Web Services Interoperability Organization), e W3C (World Wide Web

Consortium).

Alm das entidades supracitadas, grandes empresas como IBM, Intel, Google, Nokia,

Oracle, SAP, SUN, e muitas outras, esto diretamente envolvidas com a criao

especificaes. Algumas destas empresas desenvolvem frameworks para serem utilizados na

Arquitetura Orientada a Servio e nos Servios Web.

Porm, a abordagem adotada pelas empresas e corporaes recorrentemente, baseada

na arquitetura centralizada tradicional ou na troca excessiva de mensagens, gerando um alto

grau de dependncia entre as entidades instanciadas nos diferentes domnios.

A literatura cientfica apresenta algumas propostas de como implementar sistemas

distribudos de controle de acesso, porm, em geral, estas no conseguem atender

satisfatoriamente aos princpios de baixo acoplamento almejados pela AOS. Pois, os modelos

propostos so na verdade modelos tradicionais (i.e.: centralizados) adaptados para atender as

necessidades da AOS e dos WS.

Neste trabalho ser desenvolvido o modelo de provisionamento, seguindo uma srie

7

de padres para manter a compatibilidade e interoperabilidade com qualquer outra Arquitetura

Orientada a Servio ou Servios Web.

O modelo de avaliao de polticas baseado no paradigma de provisionamento ainda

no foi integrado ao contexto dos Servios Web, visto que a maioria dos padres e

especificaes existentes ainda segue a abordagem tradicional, induzindo assim o seu uso e

implementao.

A abordagem tradicional facilita a gerncia de polticas, pois centraliza a mesma em

um nico ponto, porm, com esta centralizao da administrao gera-se o ponto nico de

falhas no sistema.

O presente trabalho oferece uma alternativa abordagem tradicional, promovendo a

administrao descentralizada de polticas usando o modelo de provisionamento e a concesso

de direitos atravs de certificados de autorizao.

Como adicional, no caso de uma solicitao de acesso que seria negada na abordagem

tradicional, com a integrao dos certificados de autorizao, o principal tem uma alternativa

para obter o direito desejado. Ou seja, mesmo se o principal no estiver inserido nas polticas

de controle de acesso configuradas no provedor de servios da filial, este pode recorrer ao

administrador de seu domnio e obter tal direito.

1.2 Objetivos

O objetivo geral deste trabalho criar um modelo de controle de polticas fracamente

acoplado com o auxlio de uma arquitetura de autenticao e autorizao flexvel. Com a

unio dessas abordagens, visa-se o desenvolvimento de um sistema distribudo de controle de

acesso de baixo acoplamento, possibilitando a transposio transparente dos domnios de

segurana, tanto para principals (i.e.: clientes) quanto para provedores.

A integrao de alguns dos padres e infra-estruturas existentes facilitar o

gerenciamento das polticas corporativas utilizadas nas entidades distribudas, a aquisio de

credenciais de acesso, e a implantao de caractersticas que tornaro os sistemas mais

independentes no provimento de servios bem como os principals no acesso aos mesmos.

Mais especificamente este trabalho visa:

Modelar uma Arquitetura Orientada a Servio fazendo uso de alguns dos vrios

8

padres existentes visando o baixo acoplamento e a interoperabilidade. Esta

abordagem visa prover uma arquitetura padronizada e amplamente aceita.

Propor um procedimento flexvel de autenticao e autorizao distribuda, diminuindo a troca de mensagens entre principals e provedores ou entre seus

respectivos domnios, bem como agilizar o processo de autorizao dentro do domnio

do provedor.

Propor um modelo de mensagem apoiado nos padres existentes, utilizado o mesmo para transportar a credencial contendo a identificao, os atributos e os privilgios de

acesso do principal. Evitando-se assim a troca de mensagens com outras entidades

(e.g.: servios de atributos). Esta abordagem evita a necessidade da instanciao de um

servio para fornecer atributos sobre o principal, ou que este necessite de

conhecimentos especficos dos mecanismos de controle de acesso e ou autenticao

implementados no provedor de servios.

Propor um modelo que de autonomia local ao provedor de servios sem violar as polticas corporativas. Este objetivo ser implementado usando o modelo de

provisionamento e certificados de autorizao.

Propor um modelo para manter os repositrios de polticas (corporativo e das filiais) sempre atualizados e sincronizados.

Propor um mecanismo de execuo de polticas que aceite mais de um tipo de credencial (e.g.: assertivas de autorizao, certificados de autorizao) para autenticar

e autorizar o principal no acesso a recursos.

Propor um modelo que distribua os controles de autorizao de maneira segura, visando facilitar o uso da concesso de direitos. Direitos estes transportados pelos

certificados de autorizao.

Propor um mecanismo (parser) que faa uso dos certificados de autorizao para extrair os parmetros necessrios para a gerao de polticas de fina granularidade que,

posteriormente, iro conceder direitos de acesso a recursos para os respectivos

principals.

Propor um mecanismo (parser) que faa uso de certificados de autorizao para extrair os parmetros necessrios para a gerao de uma credencial de acesso, a qual

utilizada para fornecer acesso imediato ao respectivo principal que solicitou acesso.

Utilizar as especificaes de segurana disponveis para descrever as restries de

9

acesso exigidas pelos servios, padronizando o estabelecimento de relaes de

confiana entre os principals e os domnios dos provedores de servio.

Propor um esquema para transportar e armazenar as polticas de maneira segura entre os repositrios (e.g.: corporativo e da filial) durante a fase de provisionamento.

Propor um esquema para enviar e armazenar as novas polticas de maneira segura para o repositrio da corporao.

Propor uma infra-estrutura de execuo de polticas que possa atuar no modelo de provisionamento e tradicional.

Implementar as entidades e os mecanismos propostos como Servios Web. Implementar o prottipo do caso de uso, o qual tem a finalidade de avaliar a proposta e

testar sua aplicabilidade.

1.3 Organizao

A presente dissertao est organizada da seguinte maneira. O Captulo 2 apresenta a

Arquitetura Orientada a Servio, o protocolo de transporte de mensagens, bem como a

linguagem padronizada utilizada para a troca das informaes transportadas pelas mensagens.

So tambm apresentados os Servios Web. O Captulo 3 descreve os principais padres

utilizados para proteger as informaes trocadas entre as entidades da AOS, bem como

algumas das especificaes utilizadas para padronizar e assegurar a troca de informaes em

ambientes de Servios Web. O Captulo 4 apresenta os principais modelos de segurana e

controle de polticas adotados no trabalho. Este captulo traz algumas especificaes

adicionais para Servios Web, sendo estas as mais utilizadas em processos de avaliao de

polticas de controle de acesso, e transporte de informaes de maneira padronizada entre

diferentes domnios de segurana. O Captulo 5 apresenta alguns dos principais esforos da

literatura em propor modelos de baixo acoplamento, seguros e escalveis, os quais podem ser

utilizados para atender algumas das preposies da AOS. O Captulo 6 aborda o modelo

proposto. Neste captulo apresentado um modelo genrico para AOS, o modelo proposto

para Servios Web, e a dinmica de um caso de estudo utilizando Servios Web. O Captulo

7 mostra as avaliaes feitas no prottipo implementado, expondo as tecnologias que

auxiliaram no desenvolvimento do modelo proposto bem como alguns detalhes de

10

implementao, visando esclarecer e facilitar o entendimento do todo. E finalmente, o

Captulo 8 apresenta as concluses e anlises feitas com base no captulo anterior. Neste

captulo so apresentados, tambm, possveis trabalhos futuros.

11

Captulo 2

2. Arquitetura Orientada a Servio e Servios Web

2.1 Introduo

A expanso das redes de comunicao est fazendo organizaes situadas

geograficamente distantes vislumbrarem a possibilidade de integrar seus sistemas e, tambm,

oferecer servios a usurios da Internet.

Com a expanso, surge tambm a necessidade de diferentes sistemas trocarem

informaes uns com os outros de forma independente a plataforma, tornando-se necessrio

uma padronizao para favorecer o funcionamento interopervel dos sistemas. Promovendo

com isto a troca de informaes em ambientes heterogneos.

Os documentos criados por organizaes como OASIS, W3C, WS-I, estabelecem

padres que possibilitam a troca de informaes de maneira neutra plataforma. Estes

documentos abordam, tambm, questes de segurana relacionadas a troca de informaes.

Neste captulo ser apresentada a Arquitetura Orientada a Servio, a qual forma o

modelo base para os Servios Web.

2.2 Arquitetura Orientada a Servio (AOS)

A Arquitetura Orientada a Servio AOS (Service Oriented Architecture SOA) [5]

tem como um de seus objetivos propor uma estrutura para disponibilizar servios que

realizem determinada tarefa para atender alguma demanda.

Pode-se dizer, a princpio, que a AOS prope um sistema distribudo genrico, que

no est restrito a uma tecnologia particular (e.g.: Common Object Request Broker

Architecture - CORBA, Servios Web). A AOS possui agentes (e.g.: hardware, software)

12

operando em diferentes ambientes, porm trabalhando juntos para um fim comum. Por ser

uma arquitetura distribuda, a comunicao entre os agentes pode ser mais lenta e menos

confivel se comparada a tecnologias que usam invocao direta de mtodos [6].

Os agentes podem ser descritos como sendo de dois tipos bsicos: (1) o cliente,

caracterizando o principal solicitando acesso a um recurso. Principal um termo genrico

utilizado para designar qualquer entidade (e.g.: humano ou programa) que est solicitando

acesso a um servio; (2) o agente provedor ou provedor de servio, responsvel por

implementar e prover o servio (e.g.: armazenamento e pesquisa de dados, processamento de

tarefas, etc.). Os termos servio e recurso sero usados de maneira intercambivel durante a

exposio do texto para designar o objetivo almejado pelo principal.

A Arquitetura Orientada a Servio permite realizar a construo, disponibilizao e

utilizao de servios distribudos, sendo uma de suas caractersticas o fraco acoplamento

entre o principal e o servio. Ou seja, o principal no necessita conhecer os detalhes internos

de funcionamento ou invocao de mtodos do provedor que atender a solicitao. Desta

forma permitido ao principal utilizar outro provedor de servio acessvel em outro endereo

da Internet, caso o recurso fornecido atualmente falhe ou o mesmo no atenda mais as

necessidades do principal [7], por exemplo.

Este modelo de arquitetura de sistemas distribudos caracterizado em termos do que

o servio faz e na interao que ocorre durante a troca de mensagens entre o principal e o

provedor. As mensagens so enviadas em um formato padronizado por meio da interface

disponibilizada pelo servio. A interface expe somente os detalhes importantes para o uso do

servio. A descrio do modelo conceitual da Arquitetura Orientada a Servio pode ser

encontrada no Apndice A.1.

A descrio de um servio exposto, segundo a AOS, pode incluir polticas associadas

com o mesmo, fornecendo as informaes necessrias para o principal avaliar se o servio

opera de maneira consistente com seus requisitos. A poltica pode descrever restries ou

condies de uso para principals e provedores. Estando ambas as partes de acordo com as

polticas, estas sero usadas para regrar a interao entre as entidades.

A AOS enfatiza a implementao de seus componentes como mdulos de servio, os

quais podem ser descobertos e usados por principals. Os servios podem ter propsitos

individuais, ou podem ser integrados para executar um fluxo de trabalho mais complexo,

dependendo assim da agregao de outros servios.

13

Na seo 2.5 ser apresentada uma implementao da AOS baseada na web (i.e.:

Servios Web) que fortemente fundamentada em XML (Extensible Markup Language) e

SOAP (Simple Object Access Protocol). Estes assuntos sero brevemente abordados nas

Sees 2.3 e 2.4 respectivamente, para facilitar o entendimento dos Servios Web.

2.3 Linguagem de Marcao Extensvel (XML)

A XML (Extensible Markup Language) [8] uma linguagem de marcao extensvel

muito utilizada para descrever os dados trocados entre os servios, por exemplo. Sua

capacidade de extenso decorre do fato que qualquer estrutura de dados que possa ser descrita

com caracteres, pode ser delimitada por tags XML.

As limitaes da linguagem so impostas pela prpria estrutura dos dados. Sendo

assim, qualquer indivduo pode fazer uso da XML e criar sua prpria definio de tipos de

dados. As tags servem para fazer a marcao do contedo do documento XML, identificando

a sua estrutura e as informaes contidas neste, estruturando assim o contedo do documento.

Toda estrutura de dados convertida para XML referenciada como um documento

XML, o qual est tipicamente associado a um esquema. O esquema especifica as regras de

gramtica, as tags permitidas, a estrutura das tags, o tipo de dados que se espera encontrar,

entre outras regras que se queira definir. Se o documento XML estiver de acordo com seu

esquema, o mesmo ser validado pelo receptor e processado de forma correta.

Os dois tipos mais comuns utilizados na validao de documentos XML so o DTD

(Document Type Definition) e o esquema (XML Schema) [9]. Estes descrevem o contedo

permitido em documentos XML. Assim possvel realizar a validao do documento XML

recebido de acordo com as regras especificadas em um dos documentos citados acima.

DTD um documento de texto que descreve o formato dos dados presentes em um

documento XML, porm, no sendo formatado em XML. Schema um tipo de validao de

dados formatado em XML, mais atual e tambm mais utilizado, que tambm serve para

definir a estrutura do documento XML.

O documento XML dito bem formado ou vlido se este atende a todos os requisitos

de um ou mais esquemas. Um documento XML vlido pode ser interpretado como um

documento compartilhado e entendido entre as partes.

O padro XML faz uso do espao de nome (namespace), permitindo a definio do

14

domnio no qual o vocabulrio definido dentro de um documento XML vlido. Estes

domnios so geralmente referenciados por uma URL (Uniform Resource Locator).

Freqentemente a URL resolve para uma pgina web que prov a documentao sobre

o espao de nomes utilizado, assim como informaes sobre o tipo de converso de dados

usada. A URL pode ser usada para definir prefixos, usados na identificao de nomes de

elementos em documentos XML.

Documentos XML emitidos por diferentes entidades podem possuir elementos com

nomes semelhantes. Para resolver possveis conflitos de nomes, a XML Namespaces faz uso

do conceito de nomes qualificados (i.e.: QNames), uma combinao da URL e um nome

local, ambos fornecidos por quem emitiu o documento. Assim, independente do contexto, o

nome ser sempre nico.

Uma das principais vantagens do XML para os Servios Web a independncia dos

dados. Os tipos de dados e estruturas dos documentos no so vinculados com as

implementaes subjacentes dos servios, como uma linguagem de programao especfica,

por exemplo. As aplicaes convertem os dados para XML e depois fazem o processo

inverso, trazendo novamente o dado para o formato nativo de cada plataforma.

O fragmento de um documento XML mostrado na Figura 2.1 expe os cdigos da

linguagem XML, mostrando os atributos de um livro. Na hierarquia do documento XML,

aps o elemento livro, tm-se os elementos que descrevem o livro.

Java: Como Programar. 6 Edio Deitel 200,00

Figura 2.1: Fragmento de um documento XML

A XML tem sido aceita como a linguagem para descrever os dados trocados em

ambientes de Servios Web, sendo aplicada na definio e formatao de dados, serializao,

e transformao destes em um formato padro.

A comunicao com os Servios Web geralmente ocorre atravs da troca de

documentos XML encapsulados em mensagens SOAP (Seo 2.4). Este protocolo carrega

solicitaes e respostas durante a interao com os Servios Web.

15

2.4 Protocolo Simples de Acesso a Objetos (SOAP)

O protocolo SOAP (Simple Object Access Protocol) [10] est baseado no padro

XML. Esse utilizado na troca de informaes em ambientes distribudos e ou heterogneos.

O SOAP prov um formato de mensagem comum para a troca de dados entre agentes

solicitantes (i.e.: principals) e provedores, ou outros componentes da arquitetura.

A mensagem SOAP pode trafegar sobre uma variedade de protocolos subjacentes

(e.g.: Hypertext Transport Protocol HTTP, Simple Mail Transport Protocol SMTP).

Apesar de ser um protocolo para troca de mensagens, o padro no especifica que toda

mensagem SOAP enviada a um destinatrio necessita ter uma resposta.

A mensagem SOAP composta basicamente de trs elementos: o envelope, um ou

mais cabealhos e o corpo (Figura 2.2).

Envelope: delimita o incio e o fim da mensagem. Esse ainda composto por mais dois elementos: o espao de nomes XML, que especifica o nome completamente

qualificado (QName); e o estilo de codificao, identificando o tipo dos dados usados

na mensagem SOAP.

Figura 2.2: Mensagem SOAP

Cabealho: no um elemento obrigatrio, mas se estiver presente pode ser usado para carregar informaes sobre a qualidade do servio ou informaes referentes a

segurana (definidas na especificao WS-Security [11]). Se informaes adicionais

estiverem presentes, um determinado n intermedirio (i.e.: processo ou servio entre

16

o agente solicitante e provedor) pode executar algum processamento adicional, alm

do processamento executado pelo destinatrio final da mensagem.

Corpo: contm os dados (i.e.: payload) ou parmetros da mensagem SOAP, direcionados a um destinatrio.

2.5 Servios Web

Os Servios Web (Web Services WS) [6] implementam a AOS, tendo como um de

seus propsitos promover a interoperabilidade entre diferentes sistemas, instanciados em uma

diversidade de plataformas. Sistemas que tipicamente interagem usando mensagens SOAP

(Seo 2.4) transportadas por HTTP, tendo a serializao dos dados baseada em XML (Seo

2.3).

Servios Web o termo usado para se referir a determinado servio implementado de

maneira concreta em um provedor. A troca de mensagens via HTTP e a orientao a servio

so algumas das caractersticas que descrevem o fraco acoplamento entre o principal e o

provedor [12]. Uma descrio mais concreta da arquitetura geral dos Servios Web pode ser

encontrada no Apndice A.2.

O servio por sua vez implementado em alguma linguagem de programao

particular e descrito seguindo uma especificao processvel por mquina, a WSDL (Web

Services Description Language, Seo 2.5.1). A WSDL define os parmetros aceitos pelo

servio e como ocorrer a interao com o mesmo. Geralmente, todos os Servios Web

trazem consigo a semntica da operao, refletindo o propsito e a implicao de sua

invocao.

Para que a interao entre as entidades possa ocorrer de maneira satisfatria, algumas

premissas devem ser satisfeitas: o principal e o provedor devem concordar na descrio, na

semntica e na poltica utilizada para manter o servio seguro. A poltica deve ser

compreendida pelo principal e implementada pelo provedor.

Na Figura 2.3 mostram-se as principais entidades da arquitetura dos Servios Web e a

possvel interao entre as mesmas no processo de criao, publicao e acesso a um

determinado servio anunciado por um provedor.

Aps a criao do servio no provedor (evento 1, Figura 2.3) gera-se o documento

17

WSDL que descreve o servio e publica-se o mesmo na UDDI (Universal Description

Discovery and Integration, evento 2). A UDDI tem a funo de repositrio, utilizada para

armazenar documentos WSDL. Uma descrio mais detalhada sobre a UDDI pode ser

encontrada no Apndice A.3. O principal a procura de determinado servio, entra em contato

com o servio UDDI atravs de algum mecanismo de pesquisa (evento 3) para obter o

documento WSDL (evento 3.1).

De acordo com as informaes obtidas do documento WSDL, implementa-se o

programa cliente (evento 4). Os dados da solicitao sendo enviada ao provedor de servio

(evento cinco) so serializados em XML e encapsulados em mensagens SOAP. Neste caso o

protocolo de transporte subjacente o HTTP. Aps o processamento empreendido pelo

provedor, o mesmo pode retornar uma mensagem (evento 5.1) transportando a resposta da

solicitao feita anteriormente.

Figura 2.3: Principais entidades que compem a arquitetura dos Servios Web

Em Servios Web, geralmente, as mensagens so trocadas entre principals e

provedores geograficamente distantes, assim pode ser necessrio um grau de certeza que a

mensagem foi entregue, e que tanto o emissor quanto o receptor tiveram o mesmo

entendimento da mensagem.

O grau de certeza requerido em alguns tipos de Servios Web pode ser alcanado

usando-se especificaes adicionais, agregando-se certo nvel de garantia na troca de

18

mensagens entre as entidades (i.e.: principal e provedor). Mais detalhes sobre algumas

especificaes que provem tais garantias podem ser encontrados no Apndice A.4.

2.5.1 Linguagem para Descrio dos Servios Web (WSDL)

A WSDL (Web Services Description Language) [13] define a estrutura de documentos

de acordo com o formato XML, podendo ser usada para descrever os componentes

necessrios para se realizar alguma interao com os Servios Web. A WSDL visa assegurar a

independncia de plataforma e linguagem de programao.

A descrio do servio divide-se em dois nveis, sendo um deles genrico e um

concreto. No nvel genrico a WSDL descreve os Servios Web em termos de mensagens

enviadas e ou recebidas. Mensagens tipicamente descritas de acordo com o XML Schema. Em

nvel concreto, a WSDL especifica a ligao (binding), ou seja, o tipo de transporte usado na

comunicao entre principals e provedores, e detalhes do formato de uma ou mais interfaces

que compem o servio. O documento criado de acordo com o formato da WSDL pode ser

processado por programas de computadores especficos e tambm interpretado manualmente

por humanos.

Para se diminuir a quantidade de falhas durante as interaes, cada mtodo no

provedor de servios deve ser inequivocamente identificado pelo seu nome qualificado (i.e.:

QName). Isto , se dois mtodos distintos esto no mesmo espao de nomes do provedor,

ento esses devem ter QNames nicos.

Para haver interao entre o principal e o provedor de servio, estes devem concordar

com o formato do documento WSDL. O principal, primeiramente, deve localizar (evento 3,

Figura 2.3) a descrio do servio, a qual contm as informaes de como interagir com

servio bem como a sua localizao (e.g.: URL). Com a WSDL, implementa-se o cliente

(evento 4) e envia-se uma determinada mensagem com os devidos parmetros para o provedor

que est fornecendo o servio (evento 5). O provedor responsvel por manipular a

mensagem recebida, e caso necessrio devolver uma resposta para o endereo determinado na

mensagem (evento 5.1).

19

2.6 Concluso

A Arquitetura Orientada a Servio e os Servios Web esto sendo vistos como a base

para uma nova gerao de aplicaes distribudas e ferramentas para gerenciamento de

sistemas [12].

A neutralidade a plataforma com a qual os Servios Web podem ser implementados e

acessados, de maneira local e ou remota, um dos fatores que tem impulsionado a

padronizao de sua arquitetura. Vrias empresas usam e desenvolvem novas e aperfeioadas

especificaes para que este tipo de sistema distribudo ganhe mais adeptos.

O prximo captulo abordar os principais esforos de organizaes como OASIS e

W3C em produzir documentos, visando padronizar este meio um tanto quanto conturbado

pela evoluo constante que os sistemas sempre esto passando.

Captulo 3

3. Padronizao para XML e Servios Web

3.1 Introduo

Mecanismos de segurana tradicionais como SSL/TLS (Secure Sockets

Layer/Transport Layer Security), IPSec (Internet Protocol Security) e VPN (Virtual Private

Network), so tecnologias utilizadas para proteger conexes ponto-a-ponto. Embora tais

tecnologias sejam usadas na segurana de Servios Web, estas no so suficientes para prover

segurana fim-a-fim, em nvel de mensagem SOAP, como os Servios Web necessitam [6].

Uma das justificativas para as preocupaes com a segurana em Servios Web o

fato de o protocolo SOAP ser firewall friendly [14]. Ou seja, ele passa pelo filtro de pacotes (e

pela porta 80) como se fosse trafego HTTP normal. Tendo esta passagem livre, pessoas mal

intencionadas podem fazer uso de mensagens SOAP para realizar ataques aos servios

fornecidos pelo provedor.

Entre os vrios tipos de ataques que a mensagem SOAP pode sofrer, podem-se

destacar aqueles que comprometem a confidencialidade e a integridade, os quais podem ser

inibidos pelo uso da cifragem de dados e tcnicas de assinatura digital.

A mensagem SOAP pode passar por vrios ns intermedirios antes de atingir seu

destino, ento segurana em nvel da mensagem importante ao invs de somente ponto-a-

ponto. O contexto de segurana aplicado a mensagem SOAP fim-a-fim, ou seja, mesmo

aps o recebimento da mensagem no n de destino, a mesma continua protegida pela cifragem

e assinatura.

Porm, pode haver casos em que um n intermedirio necessita ter acesso a alguma

informao transportada pela mensagem SOAP, em uma situao que o n intermedirio est

entre o solicitante e o destinatrio. A WS-Security [11] estabelece regras e modelos para que

21

somente partes especficas da mensagem sejam cifradas, deixando as demais partes em texto

claro para os ns intermedirios terem acesso as informaes.

Ataques do tipo repetio, man-in-the-middle, spoofing e negao de servio tambm

comprometem a interao segura entre as partes. Alguns mecanismos de autenticao como

os propostos pela especificao WS-Security podem ser usados para autenticar os principals,

reduzindo assim os riscos de fraudes. Dentre os mecanismos podem-se incluir a criptografia,

sistemas de autenticao baseados em usurio/senha, one time pass, timestamp, certificados,

etc. Aps o principal estar autenticado, mecanismos de autorizao podem controlar o acesso

do mesmo aos recursos do sistema.

O presente captulo aborda, brevemente, alguns dos principais esforos na criao de

padres para tentar solucionar alguns dos problemas citados acima.

3.2 Padres de Segurana para XML

Para proteger as informaes encapsuladas em documentos XML foram criados

padres que visam suprir tal demanda.

Padres como o XML Encryption e o XML Signature so usados para proteger o

contedo da mensagem SOAP, fornecendo garantias para que as informaes trocadas entre

os agentes (i.e.: principal e provedor) no sejam indevidamente alteradas durante seu

transporte na rede.

3.2.1 XML Encryption

O padro XML Encryption [15] define um processo para cifrar dados digitais e a

forma como o resultado do processo de cifragem deve ser representada em um documento

XML. Os dados cifrados podem ser uma seqncia de caracteres, dados binrios, um

elemento XML, o contedo de um elemento ou um documento XML inteiro.

O processo de cifragem prov a confidencialidade do dado cifrado, podendo ser

executado por algoritmos de chave simtrica ou assimtrica. O XML Encryption tambm

suporta uma super-cifragem de dados, isto , um dado j cifrado pode ser novamente cifrado.

O resultado do processo de cifragem colocado em um elemento chamado

dentro do documento XML. Este documento, alm de carregar o dado

22

cifrado, pode fornecer informaes sobre o tipo do algoritmo utilizado, tamanho da chave

usada para o processo de cifragem, etc. As informaes adicionais servem para que o receptor

possa decifrar a mensagem. Caso estas informaes sejam omitidas, espera-se que o receptor

j as conhea previamente.

As Figuras abaixo mostram o resultado de um processo de cifragem. A linha 1

(Figuras 3.1 e 3.2) mostra a verso do XML que est sendo usada. A linha 2 (Figuras 3.1 e

3.2) descreve informaes sobre determinado pagamento, juntamente com o espao de nomes

(URI - Uniform Resource Identifiers). A linha 3 (Figuras 3.1 e 3.2) informa o nome do sujeito

que est efetuando o pagamento.

1. 2. 3. John Smith 4. 5. 4019 2445 0277 5567 6. Example Bank 7. 04/02 8. 9.

Figura 3.1: Documento XML em texto claro

Entre as linhas 4 e 8 (Figura 3.1), juntamente com os elementos aninhados em sua

estrutura, esto as demais informaes referentes ao pagamento que o sujeito est efetuando

(e.g.: a moeda em circulao, o nome do banco, data). A linha 9 encerra o documento XML,

indicado pela marcao .

1. 2. 3. John Smith 4. 7. 8. A23B45C56 9. 10. 11.

Figura 3.2: Documento XML cifrado

23

A julgar pelo fato que as informaes referentes ao pagamento (e.g.: limite, nmero de

carto de credito) so consideradas sensveis e no deveriam ser expostas (linhas 4 a 8, Figura

3.1), as mesmas necessitam ser protegidas para no serem reveladas.

Entre as linhas 4 e 9 (Figura 3.2) est o elemento que transporta as informaes de

maneira cifrada, juntamente com o espao de nomes referente XML Encryption. Entre as

linhas 6 e 8 esto os elementos definidos na especificao e o dado cifrado (elementos entre

as linhas 4 e 8, Figura 3.1).

No exemplo citado na Figura 3.2, o emissor e o receptor do documento XML cifrado

devem possuir um segredo compartilhado, pois o presente documento no fornece nenhum

tipo de informao adicional (e.g.: tamanho da chave, algoritmo criptogrfico) que auxilie no

processo de decifragem do documento XML.

3.2.2 XML Signature

O XML Signature [16] define como o dado ser assinado e como o resultado da

assinatura deve ser representada em um documento XML. Com este padro, todas ou apenas

partes especficas de um documento XML podem ser assinadas. O XML Signature pode ser

aplicado sobre qualquer contedo digital, incluindo o contedo de um ou mais servios.

O uso deste padro assegura autenticidade, integridade e no repdio nas interaes

com algum servio. O XML Signature pode ser usado por aplicaes distribudas para

autenticar a identidade do emissor de uma mensagem ou documento, ou aferir que as

informaes transportadas pela mensagem no foram alteradas enquanto eram conduzidas

pela rede. O emissor tendo assinado o documento XML, no pode negar a sua emisso, pois

somente esse deveria conhecer a chave para realizar a assinatura, por exemplo.

A assinatura digital mais complexa de ser implementada do que a cifragem, porque

essa vinculada matematicamente com a representao do dado sendo assinado. O dado pode

ser um resumo (hash) ou o prprio dado. Deve-se ter cuidado na verificao da consistncia

do dado, sendo que este procedimento sensvel a ordem de processamento efetuada pelas

partes que trocaram alguma informao assinada e ou cifrada.

Mesmo a assinatura sendo vlida, em seu perodo de criao, a mesma pode no ser

verificvel devido a mudanas ocorridas durante o transporte da mensagem. O elemento

quem transporta o contedo da assinatura, esse pode ser o elemento XML de

24

nvel mais alto na hierarquia da estrutura ou pode estar aninhado em alguma tag dentro do

documento XML. A padronizao dos dados efetuada antes do processo de assinatura feita

pelo padro XML sob a forma cannica [17] (Seo 3.2.3).

Uma assinatura pode ser associada com um documento de trs diferentes modos: (1)

enveloped e (2) enveloping: acompanhando o documento XML ao qual referenciam, e (3)

detached: o dado assinado est fora do elemento , sendo apenas referenciado na

estrutura da assinatura.

3.2.3 XML Canonical

O padro XML sob a forma cannica [17] define regras para transformar um

documento XML em uma representao padro. Esse estabelece mtodos para determinar se

dois documentos so idnticos, e ou no foram trocados durante o transporte, efetuando uma

padronizao dos elementos do documento antes do processo de resumo e ou assinatura.

O XML Canonical utiliza a tcnica de resumo (hash) intolerante a mnimas mudanas

em um documento. Mesmo a introduo de um espao em branco produz um resumo

diferente. Essa intolerncia essencial para a produo de um resumo seguro. Deve ser

prximo do impossvel de modificar o documento original de tal modo que o documento

alterado ainda produza o mesmo resumo.

Para se utilizar esta tcnica de maneira satisfatria, cuidados devem ser relevados,

visto que documentos XML so freqentemente analisados ou re-analisados durante o seu

transporte do emissor at o receptor. As analises podem fazer alguma mudana significante,

(e.g.: eliminando um espao em branco) comprometendo a validao da assinatura por parte

do receptor. Sendo que o emissor e o receptor deveriam computar o mesmo resumo, sem levar

em considerao os processos (analises) ocorridos durante o transporte na rede, por exemplo.

O XML sob a forma cannica permite que se assine somente o resumo da mensagem

ao invs da mensagem inteira. Tendo isto agrupado a algoritmos de resumo adequados,

garante-se a autenticidade e a integridade da mensagem.

3.3 Padres para Servios Web

Inmeras so as especificaes disponibilizadas para Servios Web, nesta seo sero

25

descritas as que mais tm relao com o presente trabalho.

Documentos como o Basic Profile [18] e o Basic Security Profile [19] fornecidos pela

organizao WS-I (Web Services Interoperability Organization) ajudam a manter um nvel

maior de interoperabilidade entre os Servios Web. Estes documentos agregam diversas

especificaes, todas devidamente testadas, visando fornecer um perfil bsico que pode ser

seguido durante a implementao de Servios Web mais seguros.

Algumas das especificaes descritas a seguir abordam a troca de mensagem

padronizada entre principals e provedores, enquanto outras abordam a segurana na troca

destas mensagens.

3.3.1 Web Service Security: SOAP Message Security (WS-Security)

A especificao WS-Security [11] forma a base para outros padres de segurana

existentes (Figura 3.3) permitindo variedade de Servios Web interoperarem com segurana

e de maneira neutra a linguagem e plataforma.

Figura 3.3: Arquitetura de segurana dos Servios Web

A segurana alcanada agregando extenses a mensagens SOAP, fornecendo suporte

para assinatura, cifragem e representao de credenciais de segurana, provendo assim

interaes mais seguras entre diferentes domnios administrativos.

A WS-Security tenta suprir a necessidade de diferentes padres interagirem em uma

linguagem de segurana comum em nvel de mensagem, diminuindo assim a barreira imposta

por diferentes implementaes de segurana e ou domnios administrativos.

26

Os principais mecanismos providos agregam as capacidades de garantir a integridade,

confidencialidade e o mapeamento de credenciais de segurana (e.g.: certificados X.509 [20],

tickets Kerberos [21], asseres SAML Security Assertion Markup Language, etc.) em

mensagens SOAP. As credenciais de segurana so informaes padronizadas adicionadas s

mensagens SOAP. Estas informaes podem ser descritas como uma coleo de atributos

associados ao principal que enviou determinada mensagem para o WS solicitando acesso.

Uma terceira entidade confivel (e.g.: Security Token Service STS, Certificate

Authority CA) pode aferir o contedo de uma credencial de segurana, fazendo uso de sua

chave privada para assinar e ou cifrar a credencial. Atravs destes procedimentos garante-se a

veracidade dos atributos, provando que o emissor da mensagem est de fato associado com a

credencial de segurana.

A especificao WS-Security: SOAP Message Security define trs classes de

credenciais de segurana que podem ser mapeadas para o formato XML e inseridas em

mensagens SOAP. Estas classes so do tipo nome de usurio-senha, binria e XML.

O formato de credenciais com o nome do usurio a representao do esquema

usurio-senha. O formato de credencial binria permite representar informaes como, por

exemplo, um ticket Kerberos, o certificado digital de alguma ICP (Infra-Estrutura de Chave

Pblica), etc. O formato de credencial XML pode ser usado para representar asseres SAML

ou qualquer outro tipo de esquema que possa ser mapeado para o formato XML.

3.3.2 WS-Trust

A WS-Trust [22] uma especificao que estende a WS-Security, definindo um

modelo de mensagens para o transporte de credenciais de maneira segura. Credenciais usadas

para se criar relaes de confiana intra ou inter-domnios.

A especificao define um conjunto de mensagens pedido/resposta e tambm o uso do

protocolo challenge-response [23]. Com a utilizao da WS-Trust os principals, fazendo uso

de mensagens SOAP, podem solicitar a uma autoridade confivel, no caso o STS (Security

Token Service), que determinado tipo de credencial de segurana seja emitida, renovada ou

validada em nome do solicitante. O STS um servio capaz de interpretar e emitir os mais

variados tipos de credenciais solicitadas pelo principal, porm, a especificao no define

como a interpretao ocorre.

27

O processo de emisso da credencial est baseado na identidade do principal que

agregada ao pedido enviado ao STS. Sendo estes parmetros vlidos e estando de acordo com

as polticas do STS, uma nova credencial ser emitida para o principal. O processo de

renovao est baseado na credencial que segue junto com o pedido para o STS. O STS ir

emitir uma nova credencial evidenciando uma nova data de validade. Para uma credencial de

segurana ser validada, aps a sua avaliao, um resultado deveria ser retornado ao

solicitante, este resultado pode ser o estado da credencial, uma nova credencial, ou ambos.

A especificao WS-Security define os modelos base para a criao de mensagens

seguras, a WS-Trust usa estes modelos para fazer a emisso e disseminao de credenciais de

acordo com as estruturas de segurana dos domnios. A WS-Trust, alm de permitir a

disseminao de mltiplos formatos de credenciais de segurana, considera, tambm, a

disseminao destas credenciais de maneira confivel e segura.

Para se estabelecer um relacionamento confivel entre as partes, incluem-se processos

de autenticao e autorizao que so institudos usando a troca de credenciais de segurana.

A confiana pode ser constituda entre duas ou mais partes diretamente, ou indiretamente

verificada por uma terceira parte confivel, o STS. Independentemente de como o

relacionamento foi estabelecido ou intermediado, cada parte necessita determinar, atravs de

suas prprias polticas de segurana, se a mesma pode confiar na credencial emitida por outra

parte.

O modelo fornecido pela WS-Trust est baseado em um procedimento no qual o WS

pode exigir que a mensagem recebida fornea e ou prove um conjunto de declaraes (e.g.:

nome, chave, permisso, capacidade). Um modo de provar estas declaraes apresentar uma

credencial de segurana assinada pela chave privada do STS.

O solicitante pode obter a credencial de um STS e ento encaminh-la ao provedor dos

Servios Web. O WS pode confiar na credencial emitida pelo STS, verificando a assinatura e

ou cifragem empreendida pelo mesmo, ou o WS pode solicitar ao STS que emitiu a credencial

para que este realize sua validao. Considerando a existncia de um relacionamento

confivel previamente estabelecido entre o provedor de servios e o STS.

O provedor de Servios Web, quando recebe uma mensagem SOAP transportando