Gerenciamento de Políticas de Controle de Acesso
Fracamente Acoplado para Serviços Web
Autor: Arlindo Luis Marcon Junior; Orientador: Altair Olivo Santin
Programa de Pós-Graduação em Informática (PPGIa)
Pontifícia Universidade Católica do Paraná (PUCPR)
Curitiba – PR – Brasil
{almjr, santin}@ppgia.pucpr.br
Abstract. The distributed environment of large corporations demands an
architecture for the administration of policies that provides transparency with
respect to heterogeneity. This proposal maintains a consolidated view of all
policies applied on distributed environments, taking into account the
distributed implementation of access control systems. Decentralization of
access control is achieved through policy provisioning (pre-configuration),
chains of authorization certificates and web services. The development of a
prototype using such technologies shows the feasibility of this proposal.
Resumo. O ambiente distribuído de grandes corporações necessita de uma
arquitetura de administração de políticas que forneça transparência com
relação à heterogeneidade. Esta proposta mantém a visão consolidada de
todas as políticas aplicadas em ambientes distribuídos, levando em
consideração a implementação distribuída dos sistemas de controle de acesso.
A descentralização do controle de acesso é alcançada através do
provisionamento (pré-configuração) das políticas, cadeias de certificados de
autorização e serviços web. O desenvolvimento de um protótipo utilizando
essas tecnologias mostra a aplicabilidade da proposta.
1. Introdução
A ampla difusão das redes de comunicação permite que organizações geograficamente
distribuídas vislumbrem a possibilidade de utilizar a Internet para integrar e configurar
seus sistemas, ou prestar serviços a clientes. Acessar serviços instanciados em diferentes
domínios permite interações entre corporações, filiais, clientes e os respectivos grupos
de trabalho pertencentes a cada uma destas entidades. Inerentemente as possibilidades
de interação, existe a necessidade de padronizar à troca de informações, visando
amenizar a heterogeneidade dos ambientes.
A Arquitetura Orientada a Serviço (Service Oriented Architecture) tem
demonstrado boa aceitação entre as empresas, sendo os Serviços Web (Web Services –
WS) uma de suas implementações mais utilizada. Porém, os WS herdam mecanismos
de autenticação e autorização de sistemas tradicionais, tornando-se centralizados e com
baixa flexibilidade, podendo comprometer assim a sua escalabilidade. Dependências
fortes concentram-se nos provedores de serviço e em mecanismos de autenticação e
autorização que centralizam a gerência de políticas e credenciais em um único ponto.
Um modelo de controle de acesso que aceite opções de configuração de maneira
preestabelecida e dinâmica, sem a intervenção do administrador de cada serviço é
desejado. Neste ambiente, bastaria o usuário apresentar uma credencial de autorização
para o guardião do serviço liberar o acesso ao serviço. Em um contexto como este, o
507
508
Concurso de Tese e Dissertações (CTD)
desafio é manter uma visão administrativas consolidada das políticas espalhadas pelo
domínio distribuído (e.g. provedor e filial). Mesmo fazendo uso de padrões para
Serviços Web este é um problema difícil de resolver com os modelos tradicionais.
Este artigo implementa um esquema para a configuração distribuída das
entidades responsáveis pela execução (enforcement) das decisões de avaliação de
políticas. Os privilégios de acesso de cada principal são transportados em certificados
emitidos por uma infraestrutura desprovida de autoridade certificadora. Adicionalmente,
políticas de granularidade fina são geradas dinamicamente, baseadas nos dados obtidos
das cadeias de certificados de autorização.
O artigo está organizado da seguinte maneira. A Seção 2 descreve a Arquitetura
Orientada a Serviço; a Seção 3 descreve as principais arquiteturas de controle de
políticas; a Seção 4 apresenta o modelo proposto; a Seção 5 discute os trabalhos
relacionados; e finalmente, a Seção 6 apresenta as conclusões.
2. Arquitetura Orientada a Serviço
Um dos objetivos da Arquitetura Orientada a Serviço (AOS) é prover funcionalidades
comuns para diversas aplicações (OASIS 2006a). Os Serviços Web (WS) implementam
a AOS, promovendo a interoperabilidade entre sistemas instanciados em plataformas
distintas (W3C 2004). A interação com o WS ocorre através da troca de mensagens
SOAP (Simple Object Access Protocol) (W3C 2003), geralmente transportadas via
HTTP e serializadas com base em XML (Extensible Markup Language) (W3C 2006).
Algumas das principais especificações para Serviços Web utilizadas na proposta
são brevemente descritas a seguir: a) WS-Security é utilizada para promover a
integração de diferentes padrões em uma linguagem de segurança comum em nível de
mensagem (OASIS 2006b); b) WS-Trust fornece um conjunto de mensagens pedidoresposta utilizadas no transporte de credenciais (e.g. certificados X.509) (OASIS
2006c); c) WS-Policy (W3C 2007) e a WS-SecurityPolicy (OASIS 2007a) definem um
conjunto de expressões que podem ser usadas para expor condições a principals que
desejam realizar interações com o Serviço Web (e.g. formato da credencial); d)
XACML (eXtensible Access Control Markup Language) descreve uma sintaxe XML
para a escrita de políticas de controle de acesso e um contexto de mensagens pedidoresposta, padronizando a comunicação entre o PEP (Policy Enforcement Point) e o PDP
(Policy Decision Point) (OASIS 2005a); e) SAML (Security Assertion Markup
Language) define as asserções (e.g. autenticação, atributo e autorização) que podem ser
criadas por uma terceira parte confiável (e.g. STS – Security Token Service), inseridas
em uma mensagem e associadas a um principal (OASIS 2005b); f) SAML 2.0 Profile of
XACML define um conjunto de mensagens pedido-resposta para o transporte de
contextos XACML (OASIS 2007b); g) SPML (Service Provisioning Markup Language)
define um conjunto de operações para a configuração de objetos distribuídos (e.g.
sistemas de controle de acesso) (OASIS 2006d) e h) XKMS (XML Key Management
Service) fornece serviços para o gerenciamento de chaves criptográficas (W3C 2005).
3. Arquiteturas de Controle de Políticas
As arquiteturas de controle visam garantir que as políticas impostas pelo proprietário do
serviço sejam executadas pela entidade responsável pelo enforcement. A literatura
técnica apresenta as arquiteturas baseadas em servidor (outsourcing e provisioning) e a
arquitetura baseada em certificados (SPKI / SDSI − Simple Public Key Infrastructure /
Simple Distributed Security Infrastructure).
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
509
Figura 1: Controle de políticas: Outsourcing (o) e Provisioning (p)
Controle de políticas outsourcing (modo de operação pull) (IETF 2001): é o
mais comumente encontrado na literatura técnica − é baseado em duas entidades, o
enforcement/guardião (PEP) e o monitor de referência (PDP). Nesta arquitetura, toda
solicitação de acesso recebida pelo PEP (evento o1, Figura 1) é encaminhada ao PDP
(evento o2). O PDP, com base na identidade do principal, na operação, no serviço
requisitado, e na política recuperada do repositório (evento o3) avalia a solicitação de
acesso (evento o4). O PEP é responsável por receber e honrar a decisão retornada pelo
PDP (evento o5), liberando (evento o6) ou bloqueando o acesso ao serviço que protege.
Controle de políticas provisioning (modo de operação push) (IETF 2001):
considera que a avaliação das políticas pode ser feita localmente ao PEP, em um PDP
local (LPDP). Assim, quando o PEP é inicializado, envia uma mensagem ao PDP
(evento p1, Figura 1) informando suas características para poder receber as políticas
apropriadas (operação de bootstrap). As políticas recuperadas pelo PDP (evento p2) são
enviadas ao PEP (evento p3) e armazenadas em um repositório local (evento p4). A
partir deste momento, as solicitações de acesso (evento p5) podem ser avaliadas
localmente pelo LPDP (Local PDP, eventos p4 e p6) e efetivadas pelo PEP (evento p7).
A arquitetura tradicional (outsourcing) facilita a gerencia de políticas em um
único ponto, porém torna o sistema centralizado e fortemente acoplado (dependente
funcionalmente), indo contra a proposta dos Serviços Web. A abordagem baseada em
configuração (provisioning) é mais autônoma que a outsourcing, porém nem sempre
haverão políticas disponíveis localmente para avaliar o acesso de um principal, sendo
ainda necessárias interações esporádicas com o PDP.
SPKI (IETF 1999) e SDSI (Rivest, 1996): juntos oferecem uma infraestrutura de
chave pública simples e uma arquitetura de autorização flexível. O SPKI/SDSI emprega
um modelo igualitário onde qualquer principal pode emitir certificados. A autorização é
concedida por meio dos certificados, formando uma cadeia de direitos delegados de um
principal para outro, i.e. o sujeito de um certificado se torna o emissor do próximo
certificado da cadeia. A garantia de autenticação é fornecida pela própria cadeia, sendo
que a autenticidade do principal e das delegações é baseada na assinatura digital
presente nos certificados. A cadeia de certificados pode ser reduzida em um único
certificado, que representa a interseção de todos os direitos concedidos pela mesma.
Em SPKI/SDSI o acesso a um serviço pode ser avaliado sem o auxilio de um
repositório centralizado de políticas, visto que a cadeia de certificados já concede os
direitos para a última chave (principal) da mesma. As chaves assimétricas utilizadas
para representar os principals podem ser utilizadas em processos de autenticação e
autorização, e para a geração de políticas de granularidade fina. As políticas utilizadas
nas arquiteturas de controle de acesso outsourcing e provisioning podem ser derivadas
das informações contidas na cadeia de certificados SPKI/SDSI.
510
Concurso de Tese e Dissertações (CTD)
4. Proposta
O principal objetivo deste trabalho é prover a descentralização da arquitetura de
controle de acesso mantendo a gestão consolidada de direitos/privilégios de acesso. A
descentralização na avaliação é alcançada com o modelo provisioning, sendo que o
gerenciamento consolidado é resultante da delegação de direitos através de certificados
de autorização e de um processo de atualização do repositório de políticas. As políticas
são geradas dinamicamente no domínio da filial com base nos direitos concedidos pela
cadeia de certificados de autorização e enviadas para o repositório corporativo −
mantendo-o consolidado. Esta arquitetura híbrida de controle de direitos facilita o
gerenciamento do ambiente, mantendo o baixo acoplamento entre as entidades.
O PAP (Policy Administration Point; Figura 2) armazena políticas para todos os
serviços da corporação, sendo o único repositório sujeito a atualizações administrativas
(evento up1). O LPAP (Local PAP) armazena uma copia (evento pp) das políticas para
os serviços que o PEP protege. O PEP executa a decisão de autorização (evento ac)
independentemente se a avaliação foi efetuada na filial (modelo provisioning; evento
ev1) ou em nível corporativo (modelo outsourcing; eventos av, rup e ev2).
Com a utilização do SPKI/SDSI, um principal devidamente autorizado pode
repassar seus direitos de acesso parcial ou totalmente a outro principal (eventos DRX).
Além disso, a administração corporativa pode especificar quais direitos podem ser
delegados, evitando que as concessões no domínio cliente violem as restrições da
política corporativa. Para fins de auditoria, a cadeia mantém informações sobre quem
delegou direitos para quem.
Figura 2: Modelo proposto para AOS
Quando o principal apresenta uma cadeia de autorização junto com a solicitação
de acesso (evento reqac, Figura 2) a um guardião (PEP), este a encaminha a um
Gerenciador de Chaves e Tokens (GCT2) para que a mesma seja reduzida a um
certificado único. A partir do certificado reduzido é gerada uma credencial de
autorização (evento ce) para o mecanismo que implementa o PEP e uma política para o
principal. A nova política é enviada para o repositório corporativo (PAP), representando
uma ação administrativa (evento up2). O repositório da filial (LPAP) é atualizado
sempre que necessário (eventos rup e pp) para manter a consistência com o PAP. Se o
LPAP não puder ser atualizado, gera-se uma pendência (evento np) no ambiente da
Administração Corporativa de Políticas e Credenciais (ACPC). Este esquema
descentraliza a administração de políticas mantendo as informações de autorização
consolidadas no repositório ACPC.
Com o SPKI/SDSI é possível criar relações de confiança inter-domínios (IDTR)
baseadas em certificados mutuamente emitidos entre os GCTs. As relações
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
511
inter-domínios (IDTR) permitem a concessão de direitos entre administradores (e.g.
GCT1 para GCT3). Visto que não existe uma autoridade certificadora em SPKI/SDSI,
esta é a única maneira de um principal conhecer seguramente a chave pública do outro.
As relações inter-domínios são tarefas administrativas, pois raramente o administrador
(GCTX) faz uso dos direitos que lhe são repassados. Na prática, os direitos são
concedidos aos principals do domínio cliente (evento DR3).
Os certificados permitem a transposição do domínio de autorização do cliente.
Esses transportam todos os atributos necessários para a avaliação da solicitação de
acesso. O provedor do serviço (e.g. Domínio da Filial, Figura 2) pode efetuar a decisão
de autorização baseado unicamente na cadeia de certificados.
4.1. Cenário
A seguir será considerada a aplicação da proposta em um ambiente corporativo. Este
possui funcionários ocupando diferentes cargos em vários departamentos distribuídos
pelas filiais. Para implementar os controles de segurança no cenário proposto são
utilizados Serviços Web, SPKI/SDSI e o controle de políticas provisioning.
No bootstrap do sistema, o repositório da filial (LPAP, Figura 3) é provisionado,
iniciando com o PEP enviando uma solicitação ao PDP (evento reqpp) requisitando as
respectivas políticas. O PDP recupera as políticas do repositório (PAP; eventos rup e
sgp) e as envia ao LPAP da filial (eventos spp e pp). A partir destes eventos, as políticas
estão disponíveis para serem utilizadas pelo LPDP (eventos ev1 e sp).
De acordo com a especificação da SPML (Figura 2), o PDP representa o PSP
(Provisioning Service Provider). O repositório interno ao PAP armazena as políticas, ou
PSOs (Provisioning Service Object). O PEP representa a RA (Requesting Authority), e o
LPAP representa o PST (Provisioning Service Target) que armazena as políticas, ou
PSOs. Um PDP (PSP) pode provisionar PEPs em diferentes filiais de uma corporação.
Para obter acesso a um serviço, o principal precisa ser inserido nas políticas do
LPAP, ou obter os direitos através de uma cadeia de certificados SPKI/SDSI. No evento
DR3 (Figura 3), o principal no domínio do cliente se autentica no GCT3 (STSx –
Security Token Service) enviando uma solicitação assinada contendo o serviço que o
mesmo deseja acessar. O GCT3 delega o direito exigido caso já possua a cadeia. Caso
contrário, obtém o direito solicitado pelo principal do respectivo GCT1 (evento DR2).
Se o principal em DR3 for o administrador de um departamento, o certificado
SPKI/SDSI pode ser delegável (e.g. os direitos transportados pela cadeia podem ser
repassados aos funcionários do departamento – evento DR4, Figura 2). Caso contrário, o
certificado conterá apenas os direitos para que o principal acesse o serviço no provedor.
Considerando que em determinado momento o principal envia uma solicitação
de acesso ao serviço (evento reqac, Figura 3). O Manipulador de Contexto junto ao PEP
encaminhará esta solicitação ao LPDP (evento ev1), que consultará o seu repositório.
Caso o LPDP não encontre nenhuma política referente ao principal (evento sp), esse
informa o PEP que não pode avaliar o pedido. O PEP encaminha uma solicitação de
avaliação ao PDP (evento av), pois o principal poderia estar em trânsito (e.g. não
pertence ao domínio desta filial). Neste caso, a avaliação é feita no modelo outsourcing:
o PDP na ACPC decide (evento ev2) e o PEP no domínio do provedor executa a decisão.
Caso o PDP, após consultar o PAP (eventos rup e sgp), não encontre a política
para o principal, informa-se o PEP que oferece uma alternativa de autenticação: usando
o protocolo challenge-response (NIST 1997) é devolvido ao principal uma mensagem
512
Concurso de Tese e Dissertações (CTD)
informando quais direitos são necessários para acessar o serviço. A mensagem
transporta um documento WS-Policy. O principal solicita ao GCT3 os certificados
SPKI/SDSI que concedam os direitos requeridos. Tendo obtido os direitos (evento
DR3), o principal envia a solicitação de acesso e a cadeia de certificados (evento reqac)
anexada. O PEP encaminha os certificados ao GCT2 (evento ce) para que seja feita a
conversão da cadeia em uma credencial de acesso acessível ao mecanismo (SAML).
O serviço XKMS (parte integrante do GCT2) é a entidade responsável por
validar e reduzir a cadeia de certificados, retornando um único certificado ao GCT2.
Então, o GCT2 gera uma assertiva SAML (credencial nativa de Serviços Web) baseada
nos direitos extraídos do certificado reduzido, que é serializada numa mensagem de
resposta (evento mar). O GCT2 devolve a assertiva SAML (evento ce) e o PEP libera o
acesso (evento ac) conforme as expressões (autorização ou atributo) contidas na
assertiva desserializada (evento un).
Adicionalmente, o GCT2 utiliza o certificado reduzido para gerar a política
XACML. Aplicando o SAML Profile of XACML, a nova política é enviada para o PAP
(evento up2) com a finalidade de atualizar o repositório corporativo. O PAP armazena
uma cópia da política recebida (evento sgp) e envia uma mensagem de atualização de
política (evento rup) para o LPAP usando a infraestrutura da SPML (eventos spp e pp).
Este procedimento de atualização automática de políticas é equivalente a uma inserção
de política efetuada por um administrador humano.
Figura 3: Arquitetura proposta para serviços web
4.2. Avaliação do Protótipo
A arquitetura provisioning consome 16% do tempo total da requisição (TTR) efetuada
pelo principal (evento reqac, Figura 3). Na avaliação outsourcing, o TTR sofreu um
aumento de 41% em relação ao provisioning (eventos av e ev2). Utilizando a cadeia de
certificados SPKI/SDSI (e.g. 2 certificados e 3 chaves), o GCT2 consumiu 60% do TTR,
sendo 40% para validar a cadeia e criar a política XACML e 5% para gerar a assertiva
SAML, o restante (em torno de 15%) é gasto manipulando XML. Neste contexto o PEP
consumiu 20% do TTR para aplicar o resultado obtido via assertiva SAML (evento ce).
Com o SPKI/SDSI o aumento no TTR só é percebido na primeira requisição efetuada
pelo principal, sendo que na próxima solicitação, a política já foi gerada e enviada ao
PAP (evento up2), sendo respectivamente atualizada no repositório do LPAP (eventos
sgp, rup, spp e pp). Com o SPKI/SDSI, políticas de granularidade fina foram criadas
dinamicamente sem a intervenção direta do administrador.
Usando outsourcing, toda solicitação de acesso (evento reqac) é avaliada pelo
PDP (eventos av e ev2), fazendo com que o principal e o PEP tenham que aguardar a
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
513
resposta do mesmo. Este esquema não possui baixo acoplamento (i.e. o PEP depende do
PDP), sendo computacionalmente mais custoso e dificultando a escalabilidade do WS.
Usando provisioning, o PEP aplica a decisão do LPDP, sendo este a entidade que menos
consome tempo na arquitetura. Com o SPKI/SDSI o alto TTR ocorre somente na
primeira avaliação de acesso. O esquema provisioning e SPKI/SDSI é fracamente
acoplado, dado a autonomia de operação das entidades. Esta combinação reduz o custo
humano e computacional de gestão das políticas, facilitando a escalabilidade do WS.
5. Trabalhos Relacionados
Mello utiliza um domínio intermediário para tratar tecnologias de segurança que não
interagem entre si (Mello, 2005). Os certificados (e.g. X.509) são trocados por asserções
SAML para se ter um esquema funcional. Mesmo fazendo uso de padrões difundidos, o
controle de políticas outsourcing engessa o sistema, colaborando para o aumento no
tempo de resposta e número de mensagens trocadas entre as entidades.
Camargo usa a autenticação local visando à autorização distribuída baseado na
assertiva SAML apresentada pelo cliente (Camargo, 2006). O esquema necessita que o
monitor de referência recupere atributos de serviços inter-domínios para que uma nova
credencial seja emitida (e.g. X.509), para autorizar o acesso do cliente ao serviço local.
WS-ABAC concede acesso a serviços utilizando uma credencial assinada e
munida de atributos fornecidos por entidades confiáveis (Hai-bo, 2006). A proposta
permite que decisões de autorização sejam tomadas considerando atributos e
parâmetros. Porém, o uso do outsourcing neste trabalho é indesejado devido ao forte
acoplamento já mencionado anteriormente.
6. Conclusão
Este trabalho apresentou uma proposta de gestão consolidada dos direitos de acesso
com a escrita segura e dinâmica de novas políticas. O esquema permite ao principal
cliente obter os direitos de acesso mesmo quando estes não estão presentes no
repositório da Administração Corporativa de Políticas e Credenciais (ACPC). Ao
contrário do controle de acesso clássico que neste caso negaria o pedido de acesso,
nessa abordagem o administrador do cliente delega um certificado de autorização para
que o principal seja incluído automaticamente nos repositórios do PAP e LPAP. O
SPKI/SDSI é independente de tecnologia, permitindo o transporte de direitos e o
estabelecimento de relações de confiança que podem transpor domínios de segurança.
A proposta opera automaticamente no controle de políticas provisioning e
outsourcing. Característica esta que não é encontrada em outros trabalhos relacionados.
Porém, em geral opera no modo provisioning, favorecendo a autonomia da filial, pois
cada filial possui uma cópia de suas respectivas políticas, tolerando assim uma possível
indisponibilidade da ACPC. Caso o provedor não possua políticas para um principal,
este pode obter os certificados de autorização com o administrador de seu domínio.
O esquema de segurança proposto para AOS tem baixo acoplamento, pois aplica
provisionamento de políticas e certificados SPKI/SDSI. A abordagem se mantém
compatível com o modelo baseado em servidores de autenticação e autorização, porém,
não depende destes para transpor os domínios de segurança. O protótipo implementado
comprovou a viabilidade da proposta.
7. Produção Científica & Endereço da Dissertação
514
Concurso de Tese e Dissertações (CTD)
A dissertação de mestrado referente a este artigo está disponível na URL:
www.ppgia.pucpr.br/lib/exe/fetch.php? id=teses&cache=cache&media=dissertacoes:2008:200
8_arlindo_marcon.pdf, estando diretamente relacionada com as seguintes publicações:
.
1. Marcon Jr. A. L., Santin A. O. e Stihler M., “Gerenciamento Distribuído de Políticas de Controle
de Acesso em Ambiente Corporativo”, VIII Simpósio Brasileiro em Segurança da Informação e
de Sistemas Computacionais (SBSeg08), Gramado, RS.
2. Marcon Jr. A. L., Santin A. O., Lima Jr. L. A. de P., Obelheiro R. R. e Stihler M., “Policy control
management for Web Services”, 11th IFIP/IEEE International Symposium on Integrated
Network Management (IM 2009), New York, USA.
3. Marcon Jr. A. L., Santin A. O., Lima Jr. L. A. de P. e Stihler M., “Policy Management
Architecture Based on Provisioning Model and Authorization Certificates”, 24th Annual ACM
Symposium on Applied Computing (SAC 2009), Hawaii, USA.
4. Stihler M., Santin A. O. e Marcon Jr. A. L., “Framework de Controle de Uso para Coalizões
Dinâmicas de Negócios”, XXXIV Conferencia Latino Americana de Informática (CLEI 2008),
Santa Fé, Argentina.
5. Stihler M., Santin A. O., Calsavara A. e Marcon Jr. A. L., “Distributed Usage Control
Architecture for Business Coalitions”, IEEE International Conference on Communications (ICC
2009), Dresden, Germany.
Referências
OASIS. (2006a). “Reference Model for Service Oriented Architecture”. Acesso: Ago. 2010. Disponível em:
docs.oasis-open.org/soa-rm/v1.0/soa-rm.html.
W3C. (2004). “Web Services Architecture”. Acesso: Ago. 2010. Disponível em: www.w3.org/TR/ws-arch.
W3C. (2003). “SOAP Version 1.2 Part 1: Messaging Framework”. Acesso: Ago. 2010. Disponível em:
www.w3.org/TR/soap12-part1.
W3C. (2006). “Extensible Markup Language - XML”. Acesso: Ago. 2010. Disponível em:
www.w3.org/TR/xml11.
OASIS.
(2006b).
“WS-Security”.
Acesso:
Ago.
2010.
Disponível
em:
www.oasisopen.org/specs/index.php#wssv1.1.
OASIS. (2006c). “WS-Trust 1.3”. Acesso: Ago. 2010. Disponível em: www.oasisopen.org/specs/index.php#wstrustv1.3.
W3C. (2007). “WS-Policy”. Acesso: Ago. 2010. Disponível em: www.w3.org/TR/ws-policy.
OASIS. (2007a). “WS-SecurityPolicy”. Acesso: Ago. 2010. Disponível em: www.oasisopen.org/specs/index.php#wssecpolv1.2.
OASIS. (2005a). “eXtensible Access Control Markup Language - XACML”. Acesso: Ago. 2010. Disponível
em: www.oasis-open.org/specs/index.php#xacmlv2.0.
OASIS. (2005b). “Assertions and Protocols for the OASIS Security Assertion Markup Language - SAML”.
Acesso: Ago. 2010. Disponível em: www.oasis-open.org/specs/index.php#samlv2.0.
OASIS. (2007b). “SAML 2.0 profile of XACML v2.0”. Acesso: Ago. 2010. Disponível em: www.oasisopen.org/specs/index.php#samlv2.0.
OASIS. (2006d). “Service Provisioning Markup Language - SPML”. Acesso: Ago. 2010. Disponível em:
www.oasis-open.org/specs/index.php#spmlv2.0.
W3C. (2005). “XML Key Management Specification - XKMS”. Acesso: Ago. 2010. Disponível em:
www.w3.org/TR/xkms2.
IETF. (2001). “Policy Core Information Model”. Acesso: Ago. 2010. Disponível em:
www.ietf.org/rfc/rfc3060.txt.
IETF. (1999). “SPKI Certificate Theory”. Acesso: Ago. 2010. Disponível em: www.ietf.org/rfc/rfc2693.txt.
Rivest, R. L. e Butler L. (1996). “SDSI - A Simple Distributed Security Infrastructure”. Acesso: Ago. 2010.
Disponível em: people.csail.mit.edu/rivest/sdsi10.html.
NIST. (1997). “Entity Authentication Using Public Key Cryptography”. Acesso: Ago. 2010. Disponível em:
csrc.nist.gov/publications/fips/fips196/fips196.pdf.
Mello, E. R. e Fraga, J. S. (2005). “Mediation of Trust across Web Services”. IEEE ICWS'05.
Camargo, E. T. (2006). “Transposição de Autenticação em Arquiteturas Orientadas a Serviço Através de
Identidades Federadas”. Dissertação de Mestrado. PGEEL, UFSC.
Hai-bo S., e Fan H., (2006). “An Attribute-Based Access Control Model for Web Services”, IEEE
PDCAT'06.