Post on 27-Sep-2015
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