böger, 2007 - Universidade Federal de Santa Catarina

Implementação de um Modelo de Transposição de
Autenticação para Serviços Web
Davi da Silva Böger1 , Michelle S. Wangham2 , Joni da Silva Fraga1
1
Departamento de Automação e Sistemas – Universidade Fedral de Santa Catarina
Florianópolis – SC – Brasil
2
Grupo de Sistemas Embarcados e Distribuı́dos – GSED
CTTMAR - UNIVALI
São José, SC - Brasil
[email protected], [email protected], [email protected]
Abstract. The Web Services form the basis for the interoperability among applications from different organizations. However, the security infrastructure
introduces additional complications to the transparent communication among
domains that use different security technologies. This work describes the implementation of a prototype of an authentication transposition model which allows
the Single Sign-On through different domains, even when these domais make use
of distinct security technologies.
Resumo. Os Serviços Web fornecem as bases para a interoperabilidade entre
aplicações de diferentes organizações. A infra-estrutura de segurança, no entanto, apresenta complicações adicionais à comunicação transparente entre
domı́nios que usam diferentes tecnologias de segurança. Este trabalho descreve a implementação de um protótipo de um modelo de transposição de
autenticação que permite o uso da autenticação única em diferentes domı́nios,
mesmo que estes usem tecnologias de segurança distintas.
1. Introdução
A crescente demanda pelo compartilhamento de informações tem feito com que
o modelo clássico de autenticação, centrado no provedor de serviços, seja revisto
[Jøsang and Pope 2005]. Novas formas de autenticação, como o gerenciamento de identidades federado [Lockhart et al. 2006], a facilidade Single Sign-On (SSO) [OASIS 2005a]
e o gerenciamento de identidades centrado no usuário [Vecchio et al. 2005] foram desenvolvidas para tentar resolver os problemas do modelo clássico.
Para evitar esses problemas, os provedores e clientes que usem a mesma tecnologia de segurança podem se agrupar em domı́nios para compartilhar informações e
confiar em uma terceira parte para mediar a autenticação. Além disso, domı́nios distintos podem formar relações de confiança entre si, permitindo que a autenticação em um
possa ser transposta para os domı́nios associados. No entanto, em geral os domı́nios possuem autonomia para decidir polı́ticas e tecnologias, o que torna a interoperabilidade e a
transposição mais difı́ceis.
A implementação descrita neste trabalho 1 serve para prover autenticação única em
ambientes heterogêneos, atravessando domı́nios administrativos mesmo que usem tecno1
O primeiro autor é o responsável pela totalidade da implementação descrita e pela elaboração do artigo,
tarefas supervisionadas pelos demais autores (orientador e co-orientador).
logias de segurança distintas. Para isso, o protótipo usa o modelo de transposição de
autenticação descrito em [Camargo et al. 2007]. Esse modelo se baseia em padrões de
segurança para Serviços Web e ataca o problema das diferentes tecnologias de segurança
por meio do gerenciamento de identidades federado.
Na seção 2, as tecnologias usadas no modelo de autenticação implementado são
introduzidas e, em seguida, o próprio modelo de autenticação é descrito (seção 3. A
seção 4 descreve o protótipo implementado, bem como a sua integração a um portal Web.
Alguns trabalhos relacionados são apresentados na seção 6 e, por fim, os resultados e
contribuições do protótipo implementado são descritos na conclusão.
2. Segurança em Serviços Web
Os Serviços Web [Booth et al. 2004], baseados na Arquitetura Orientada a Serviços
(AOS) e em padrões como XML [Bray et al. 2006] e HTTP [Fielding et al. 1999], formam uma tecnologia que visa padronizar a comunicação entre aplicações na Web. Essa
tecnologia provê mecanismos para troca de mensagens entre aplicações de forma a abstrair detalhes internos de implementação e sistema. As mensagens trocadas seguem um
formato padrão, definido na especificação SOAP [Mitra 2003]. Além disso, a definição
de uma linguagem para a descrição de serviços, a WSDL (Web Services Description Language) [Booth and Liu 2006], permite que as especificações funcionais dos serviços sejam obtidas e processadas dinamicamente.
A especificação WS-Security [OASIS 2006c] define formas de prover integridade e confidencialidade às mensagens SOAP usando, respectivamente, os padrões
XML-Signature [Bartel et al. 2002] e XML-Encryption [Imamura et al. 2002]. Esses dois
padrões servem para representar assinaturas e cifras no formato XML (e não apenas assinar e cifrar documentos XML). Além disso, a WS-Security também estende o padrão
SOAP para que as mensagens possam transportar diveros elementos de segurança como,
por exemplo, pares usuário/senha [OASIS 2006d], certificados X.509 [OASIS 2006e],
Kerberos tickets [OASIS 2006a] ou asserções SAML [OASIS 2006b].
A especificação SAML (Security Assertion Markup Language) [OASIS 2005a]
define uma infra-estrutura de segurança capaz de expressar, na forma de asserções,
informações de autenticação, de autorização e de atributos acerca de um sujeito. Apesar de não prover a autenticação em si, o padrão SAML permite que, uma vez realizada a
autenticação, esta possa ser usada em domı́nios diferentes por meio da troca de asserções.
O modelo de confiança nos Serviços Web é definido na especificação WS-Trust
[OASIS 2007b]. Esta especificação pressupõe que, caso um sujeito tentando acessar um
recurso não disponha das credenciais exigidas na polı́tica do provedor, este deve conhecer
alguma autoridade que possa consultar (terceira parte confiável), na tentativa de obter tais
credenciais. Na WS-Trust, essa autoridade é genericamente denominada de Serviço de
Tokens de Segurança (Security Token Service - STS) e é responsável por emitir, validar e
trocar credenciais de segurança. A WS-Trust prevê que as credenciais sejam transparentes
ao sujeito que invocar o STS, no entanto, não provê informações sobre como credenciais de um tipo especı́fico são transformadas para as credenciais exigidas no domı́nio do
provedor de serviço.
Para se poder expressar de forma uniforme e interoperável uma polı́tica em
Serviços Web, foram criadas as especificações WS-Policy [Vedamuthu et al. 2007b] e
WS-PolicyAttachment [Vedamuthu et al. 2007a]. Estas fornecem, respectivamente, uma
forma simples de expressar requisitos não-funcionais de serviços Web na forma de
polı́ticas e formas de anexar essas polı́ticas aos serviços Web. A especificação WSSecurityPolicy [OASIS 2007a] define um conjunto inicial de asserções de polı́tica, que
descrevem as caracterı́sticas de segurança definidas na WS-Security e WS-Trust, para serem usadas com a WS-Policy.
Apesar da WS-Policy poder descrever qualquer caracterı́stica de segurança, para
polı́ticas de controle de acesso, recomenda-se o uso de uma linguagem especı́fica,
a XACML (eXtensible Access Control Markup Language) [OASIS 2005b]. Esta
especificação define uma linguagem para expressar regras de polı́tica, bem como um protocolo de pedido/resposta em que diversas entidades interagem para concretizar o controle
de acesso. As principais entidades são o PEP (Policy Enforcement Point), responsável por
efetivar o controle de acesso e o PDP (Policy Decision Point), responsável por decidir se
o acesso será permitido com base em atributos do cliente e do recurso.
Outra especificação importante para o estabelecimento de confiança em Serviços
Web é a WS-Federation [Lockhart et al. 2006]. Essa especificação estende os modelos de
segurança da WS-Security, WS-Trust e WS-Policy descrevendo como devem ser combinados a fim de prover melhores mecanismos de mediação de confiança, dentro de uma
federação ou entre federações distintas. Segundo a WS-Federation, o objetivo de uma
federação é o compartilhamento de informações, como identidades e atributos, de acordo
com uma certa polı́tica que dita como será o compartilhamento, pois as informações são
freqüentemente pessoais ou confidenciais.
Na WS-Federation, o STS é estendido com as funções de provedor de identidades
(IdP) e pelo serviço de atributos e pseudônimos (APS). O provedor de identidade é um
serviço de autenticação que emite credenciais de autenticação. O serviço de atributos e
pseudônimos visa o compartilhamento de informações sobre o cliente, sempre de acordo
com a polı́tica de privacidade da federação. A fim de esconder a verdadeira identidade do
cliente, este pode usar um pseudônimo, gerenciado pelo IdP e pelo APS, por meio do qual
um provedor de serviços pode obter seus atributos sem comprometer sua privacidade.
3. Modelo de transposição
O modelo de autenticação proposto em [Camargo 2006] define uma dinâmica por meio
da qual a autenticação em um domı́nio pode ser transposta mesmo nos casos em que
a tecnologia de segurança seja diferente no outro domı́nio. Para tal, é necessário que
cada domı́nio possua uma autoridade de autenticação e de atributos, implementadas pelo
STS/IdP e pelo APS, e que estas autoridades possuam relações de confiança entre si.
A Figura 1 mostra um exemplo onde um cliente de um domı́nio que usa a tecnologia de segurança SPKI [Ellison et al. 1999] deseja acessar um recurso disponı́vel em
um provedor de serviço s pertencente a um domı́nio que usa X.509 [ITU 1993]. Uma
asserção SAML de autenticação é gerada pelo STS/IdP do domı́nio SPKI (passos 1 a 3).
Tal asserção contém atributos do cliente, e será transposta para o domı́nio X.509 juntamente com a requisição de acesso ao recurso (passo 4). O provedor de serviço realiza
o controle de acesso de acordo com sua polı́tica de segurança. No entanto, o provedor
precisa que a asserção SAML seja transformada em uma credencial que possa entender,
um certificado X.509. Para isso o seu PDP requisita ao STS/IdP do domı́nio (passo 5).
Este pode precisar invocar o STS/IdP do domı́nio do cliente para buscar os atributos necessários à geração do certificado (passo 6) para depois invocar o serviço de tradução de
Domínio SPKI
Domínio X.509
APS
Passo
2
Passo
6.1
Passo 7
STC
Passo 6
STS/
IdP
STS/
IdP
Passo
Passo
33
Passo
1
Passo5
Passo 8
Qualidade de
proteção
Passo 4
PEP
PDP
Passo 9
WS-Security
Cliente
Provedor de
WS
Figura 1. Dinâmica do modelo de transposição de autenticação
credenciais (STC) (passo 7). O STC gera o certificado para o STS/IdP que entrega para o
PDP (passo 8). O PDP pode, então, decidir o acesso do cliente ao recurso.
4. Protótipo do modelo de transposição de autenticação
Cliente
Provedor
de
Serviços
WSS4J
STC
STS/
IdP
Camada de
Aplicação
SunXACML
XMLSecurity
OpenSAML
APS
Serviços para Transposição das
Credenciais
SDSI1.2
PEP
Handler
Qualidade de Proteção
PDP
Handler
Camada de
Segurança
Controle de Acesso
SOAP + HTTP
Camada de
Transporte
Figura 2. Arquitetura do protótipo
O protótipo do modelo de transposição de autenticação desenvolvido é composto
de: um STS que acumula as funções de provedor de identidade e serviço de atributos; o
par PEP/PDP; o serviço de tradução de credenciais; e os controles de confidencialidade e
integridade nas mensagens SOAP. A Figura 2 mostra a arquitetura desse protótipo.
A configuração de software 2 usada nos ambientes de modelagem, implementação
e testes é formada das seguintes ferramentas, além daquelas mostradas na Figura 2: JUDE
para modelagem UML; J2SDK da Sun e Eclipse 3.1.1 (com JDT e plug-ins para Ant
e JUnit) para programação Java; Apache Ant para executar scripts; implementação de
SOAP Apache Axis; container Apache Tomcat; e o motor de testes JUnit.
4.1. Modelagem e Implementação
Cada STS/IdP lida com a infra-estrutura de segurança do seudomı́nio, logo para cada
tecnologia de segurança é necessário definir uma implementação de STS/IdP. Neste
2
Outros detalhes sobre as configurações e softwares utilizados podem ser encontrados no endereço
http://www.das.ufsc.br/seguranca/webservices/
protótipo, os STS/IdPs devem processar requisições de três tipos (Figura 3): (1)
requisições de autenticação de um membro do seu domı́nio; (2) requisições de pedido de
atributos na forma de asserções SAML; (3) requisições de pedido de validação de credencial, possivelmente emitida em outro domı́nio, com a subseqüente emissão de uma outra
credencial na tecnologia de segurança do domı́nio do STS. No protótipo desenvolvido,
foram implementados dois domı́nios distintos: um usando a infra-estrutura X.509 e outro
usando a infra-estrutura SPKI. Essas duas tecnologias foram escolhidas por serem infraestruturas bastante distintas, e pela existência de suporte a elas na especificação XMLSignature. Cabe apontar que a maioria das ferramentas existentes na área de segurança
para Serviços Web têm sua arquitetura voltada para X.509.
Figura 3. Requisições de emissão tratadas pelo portal
Segundo o modelo da WS-Trust, todas essas requisições são para emissão de tokens, logo, em todas as requisições, o elemento wst:RequestType do RST (RequestSecurityToken) contém o URI de emissão (http://schemas.xmlsoap.org/ws/2005/02/trust/Issue).
A diferenciação entre os tipos de requisição é feita analisando-se outros campos da mensagem (Figura 3). O funcionamento do protótipo completo está mostrado no diagrama
de comunicação da Figura 4.
Figura 4. Funcionamento do protótipo para um cliente SPKI e um provedor X.509
As requisições do tipo 1 são feitas por um cliente ao STS/IdP do seu domı́nio,
quando este deseja acessar um serviço que exija autenticação (mensagem 1, na Figura
4). O cliente recebe uma credencial de autenticação e passa essa credencial junto com
a requisição ao serviço que deseja acessar. Uma requisição de autenticação possui o
URI de asserções SAML (http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile1.1#SAMLV2.0) no conteúdo do elemento wst:TokenType. Nestas requisições, o STS/IdP
emite e assina uma asserção SAML tendo como sujeito o requerente e contendo uma
afirmação de autenticação e, possivelmente, alguns dos seus atributos.
As requisições do tipo 2 (mensagem 6, na Figura 4) também possuem o URI
das asserções SAML como conteúdo do elemento wst:TokenType, no entanto diferem das
requisições do tipo 1 pois apresentam o elemento wst:Claims, este contendo o nome do
membro do qual se deseja obter os atributos, seguido de uma lista não vazia de nomes de
atributos. Quando o STS/IdP recebe uma requisição desse tipo, este lê a lista de atributos
e acessa uma base de dados para obter os seus valores. Depois, este emite e assina uma
asserção SAML contendo os atributos do cliente.
As requisições do tipo 3 (mensagem 5, na Figura 4) são feitas pelo PDP do
provedor de serviço ao STS/IdP do seu domı́nio quando este deseja validar o token de
autenticação recebido do cliente. Nestas requisições, o elemento wst:TokenType contém
o URI indicando o tipo de credencial especı́fico do domı́nio. Quando o STS/IdP recebe
uma requisição desse tipo, este valida a asserção SAML recebida de acordo com a sua
confiança no STS/IdP emissor. Em seguida, o STC converte a asserção em uma credencial que o provedor de serviços entenda e, para isso, pode precisar de atributos do cliente.
Nesse caso, o STS/IdP faz uma requisição de atributos (do tipo 2) ao STS/IdP do domı́nio
do cliente. A credencial gerada pelo STC e assinada pelo STS/IdP é então usada pelo
provedor do serviço para obter informações sobre o cliente.
Como a implementação SOAP usada foi o Apache Axis, algumas caracterı́sticas
puderam ser implementadas usando os handlers que são componentes de software que
interceptam as mensagens SOAP nos pontos de entrada e saı́da dos clientes e serviços.
Foram criados handlers que implementam o par PEP/PDP, a confidencialidade e integridade das mensagens SOAP e a autenticação do cliente no seu STS/IdP. Este último foi
desenvolvido para simplificar a implementação de clientes que desejem usar o modelo
implementado e é o responsável por invocar o STS/IdP para autenticação (tipo 1) no lado
do cliente. Quando o handler intercepta uma mensagem SOAP saindo do cliente, este faz
uma requisição de autenticação ao STS/IdP e insere a credencial recebida no cabeçalho
da mensagem. Esta credencial, uma asserção SAML, é usada para o controle de acesso
no provedor de serviço pelos handlers que implementam o par PEP/PDP.
Com o objetivo de prover confidencialidade e autenticidade às mensagens, foram
desenvolvidos handlers baseados nas bibliotecas WSS4J e XML-Security da Apache. Os
handlers que interceptam mensagens que não saem do domı́nio de origem são especı́ficos
e usam a infra-estrutura de segurança subjacente. Os handlers que interceptam as mensagens que atravessam domı́nios usam apenas os pares de chaves dos principais para prover
confidencialidade e autenticidade, sendo que a confiança nessas chaves é verificada pelo
modelo de autenticação.
4.2. Testes de software
Com o objetivo de validar o protótipo, foram realizados testes de unidade e de sistema
sobre o mesmo. Os erros encontrados foram devidamente corrigidos e um relatório de
testes foi escrito.
Nos testes de unidade foram criados test cases, a fim de verificar a correção da
implementação dos componentes. Os test cases têm por objetivo apresentar a um compo-
nente diversos cenários diferentes, que cubram todos os aspectos possı́veis para os dados
de entrada, conferindo se as saı́das estão conforme esperado. De alguma forma, nos testes
de unidade, todos os trechos de código da unidade testada devem ser executados e verificados quanto à correção. Por essa caracterı́stica, os testes de unidade são chamados de
testes de caixa branca (o funcionamento interno dos componentes é inspecionado).
Nos testes de sistema, a abordagem é diferente. Estes testes são chamados de
caixa preta e o sistema como todo, com os seus componentes internos conectados, é validado sob a perspectiva das suas funcionalidades visı́veis externamente e não da sua
implementação interna. Por este tipo de teste, a adaptação do protótipo aos outros programas e a integração dos componentes internos é validada.
5. Integração ao Portal de Entretenimento
Um portal tem por objetivo agregar informações provenientes de diferentes origens em
uma única e simples interface, se tornando um meio de fácil acesso para os usuários do
sistema. A escolha de um portal como aplicação de teste foi devido a esta tecnologia se
mostrar muito promissora como ponto de acesso de clientes a informação distribuı́da, e
por trabalhar com o conceito de autenticação única. Por ser de fácil instalação e gerenciamento e por ser distribuı́do com licença livre, o portal Stringbeans3 foi escolhido como
infra-estrutura.
No portal desenvolvido, os clientes se cadastram para poder acessar serviços
de entretenimento pessoal, como bilheterias de shows e cinemas, compra de passagens
aéreas, reservas em hotéis, etc.. Quando o cliente se cadastra no portal, pode personalizar
seu acesso definindo quais serviços serão apresentados e a forma como serão apresentados. Além disso, o cliente fornece ao portal diversos dados pessoais que o portal cadastra
no serviço de atributos para que outros STS/IdP possam posteriormente acessar para gerar
credenciais.
Domínio SPKI
Domínio SPKI
Serviço de
Filmes em
Cartaz
SSL
Login/password
SAML asserção
STS/
IdP
Serviço de
Sinopses
Serviço de
Vendas de
Ingressos
Domínio X.509
Figura 5. Integração do protótipo ao portal
A Figura 5 mostra a integração do protótipo do modelo de transposição de
autenticação ao portal Web. Uma vez cadastrado no portal, o cliente pode se autenticar
por meio do par usuário/senha, sobre uma sessão SSL, para acessar os serviços reunidos
no portal. Seguindo o protótipo de transposição de autenticação descrito, o portal autentica o cliente no STS/IdP do seu domı́nio e depois usa essa autenticação nos domı́nios dos
3
Disponı́vel em http://www.nabh.com/projects/sbportal
provedores de serviços. Quando os provedores forem acessar o serviço de atributos no
domı́nio do portal, pedirão por atributos do cliente do portal. Dessa forma, o portal faz
a mediação do acesso dos clientes do portal aos serviços prestados pelos provedores. O
cliente do portal desfruta, então, de um contexto SSO por meio do acesso mediado.
Como
o
portal
Stringbeans
segue
o
padrão
de
Portlets
[Abdelnur and Hepper 2003] e implementa a especificação WSRP (Web Services
for Remote Portlet, diversas bibliotecas necessárias para a execução do protótipo já
estavam disponı́veis no portal. Para fazer a integração, foi necessário adicionar ao portal
as bibliotecas ausentes e implementar os portlets que se comportam como clientes SOAP
e se comunicam com o STS do domı́nio do portal e com os provedores de serviços. Os
Portlets são responsáveis também pela geração das marcações HTML que serão exibidas
no navegador do usuário. Exceto pela geração de HTML, a criação de um cliente em um
Portlet é igual a um cliente de um Serviço Web normal.
6. Trabalhos relacionados
A transposição de autenticação em arquiteturas orientadas a serviço já foi alvo
do esforço de algumas pesquisas, sendo que a maioria envolve com o conceito
de identidades federadas em Serviços Web, no entanto, se restringindo apenas ao
uso da infra-estrutura de segurança X.509. Os principais trabalhos nesse sentido
são o CredEx [Vecchio et al. 2005] e o Projeto Shibboleth [Scavo and Cantor 2005].
Em [Camargo et al. 2007], foi apresentado o modelo descrito na seção 3 e uma
implementação preliminar do modelo. Esta primeira implementação, por não tratar totalmente o modelo e por não considerar questões importantes relativas à adequação aos
padrões, como o uso do XACML e do WS-Policy, não foi suficiente para trazer à tona
todas as dificuldades envolvidas com desenvolvimento do modelo completo. O presente
trabalho é uma continuação do trabalho iniciado em [Camargo et al. 2007], sendo que
este descreve em detalhes o protótipo, agora completo, do modelo de transposição. Outras
melhorias introduzidas ao trabalho apresentado em [Camargo et al. 2007] dizem respeito
a facilidade de configuração.
O CredEx define um repositório centralizado por meio do qual um usuário pode
gerenciar suas credenciais. A implementação,entretanto, apenas prevê a associação de
um par usuário/senha a um certificado X.509, e vice-versa. O Projeto Shibboleth está
baseado no conceito de federações e permite também a transposição de autenticação e
troca de atributos por meio de asserções SAML. Entretanto, a maioria das organizações
que adotam o Shibboleth fazem uso do padrão X.509 para autenticação dos servidores e
uma autenticação baseada em senha para autenticação dos clientes.
7. Conclusão
Os principais objetivos deste trabalho foram a definição, implementação e testes de um
protótipo segundo o modelo de transposição de autenticação e, em seguida, a integração
do mesmo a um portal Web de entretenimento. Com a conclusão destes objetivos,
verificou-se a viabilidade do modelo de transposição de autenticação com base no gerenciamento federado de identidades e atributos. As principais dificuldades encontradas na implementação do protótipo foram a adequação das ferramentas disponı́veis à
infra-estrutura SPKI, que foram projetadas tendo como foco o X.509, e ainda a pouca
documentação das bibliotecas utilizadas no protótipo. A integração com o portal repre-
sentou a comprovação da aplicabilidade do protótipo em um contexto que reflete bem a
proposta do crescente compartilhamento de informações.
Os trabalhos futuros relacionados a este, alguns já em andamento, se referem
a ampliação das tecnologias de autenticação suportadas pela implementação, como
biometria, usuário/senha, tickets Kerberos, e outros. Outro trabalho importante é a
implementação do gerenciamento de pseudônimos, que contribuirá para garantir a privacidade dos clientes.
Agradecimentos
Este trabalho está sendo desenvolvido no contexto do projeto “Infra-estrutura de
Segurança para Aplicações Distribuı́das Orientadas a Serviço”, financiado pelo CNPq
(550114/2005-0).
Referências
(1993). Itu-t recommendation x.509. http://www.itu.int/rec/T-REC-X.509-199708-S/e.
Abdelnur, A. and Hepper, S. (2003).
http://jcp.org/en/jsr/detail?id=168.
Java portlet specification version 1.0.
Bartel, M., Boyer, J., Fox, B., LaMacchia, B., and Simon, E. (2002). Xml-signature
syntax and processing. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.
Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C., and Orchard,
D. (2004). Web services architecture. http://www.w3.org/TR/2004/NOTE-ws-arch20040211/.
Booth, D. and Liu, C. K. (2006). Web services description language (wsdl) version 2.0
part 0: Primer. http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327.
Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., Yergeau, F., and
Cowan, J. (2006).
Extensible markup language (xml) 1.1 (second edition).
http://www.w3.org/TR/2006/REC-xml11-20060816/.
Camargo, E., da Silva Fraga, J., Wangham, M. S., and de Mello, E. R. (2007).
Autenticação e autorização em arquiteturas orientadas a serviço através de identidades
federadas. In Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuı́dos,
Belém.
Camargo, E. T. (2006). Transposição de autenticação e de autorização em arquiteturas
orientadas a serviços através de identidades federadas. Mestrado em eng. elétrica,
Universidade Federal de Santa Catarina, Florianópolis.
Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and Ylonen, T. (1999). Spki
certificate theory. RFC 2693. http://www.ietf.org/rfc/rfc2693.txt.
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee,
T. (1999). Hypertext transfer protocol – http/1.1. ftp://ftp.isi.edu/in-notes/rfc2616.txt.
Imamura, T., Dillaway, B., and Simon, E. (2002). Xml encryption syntax and processing.
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210.
Jøsang, A. and Pope, S. (2005). User centric identity management. In AusCERT Asia
Pacific Information Technology Security Conference.
Lockhart, H., Andersen, S., Bohren, J., Sverdlov, Y., Hondo, M., Maruyama, H., Nadalin, A., Nagaratnam, N., Boubez, T., Morrison, K. S., Kaler, C., Nanda, A.,
Schmidt, D., Walters, D., Wilson, H., Burch, L., Earl, D., Baja, S., and Prafullchandra, H. (2006). Web services federation language (ws-federation) version 1.1. http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WSFederation-V1-1B.pdf.
Mitra, N. (2003). Soap version 1.2 part 0: Primer. http://www.w3.org/TR/2003/RECsoap12-part0-20030624.
OASIS (2005a). Assertions and protocols for the oasis security assertion markup language
(saml) v2.0. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
OASIS (2005b). extensible access control markup language (xacml) version 2.0.
http://docs.oasis-open.org/xacml/2.0/access control-xacml-2.0-core-spec-os.pdf.
OASIS (2006a).
Web services security:
Kerberos token profile
http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-osKerberosTokenProfile.pdf.
1.1.
OASIS (2006b). Web services security: Saml token profile 1.1. http://www.oasisopen.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf.
OASIS (2006c).
Web services security:
Soap message security
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf.
1.1.
OASIS (2006d).
Web services security:
Usernametoken profile
http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-osUsernameTokenProfile.pdf.
1.1.
OASIS (2006e).
Web services security: X.509 certificate token profile 1.1.
http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-osx509TokenProfile.pdf.
OASIS (2007a).
Ws-securitypolicy 1.2.
http://docs.oasis-open.org/ws-sx/wssecuritypolicyz-/200702/ws-securitypolicy-1.2-spec-cs.pdf.
OASIS (2007b). Ws-trust 1.3.
trust-1.3-os.pdf.
http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-
Scavo, T. and Cantor, S. (2005).
Shibboleth architecture - technical overview.
http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf.
Vecchio, D. D., Humphrey, M., and Nagaratnam, J. B. N. (2005). Credex: User-centric
credential management for grid and web services. In 2005 IEEE International Conference on Web Services (ICWS 2005), Orlando, FL. IEEE.
Vedamuthu, A. S., Orchard, D., Hirsch, F., Hondo, M., Yendluri, P., Boubez, T., and Ümit Yalçinalp (2007a). Web services policy 1.5 - attachment.
http://www.w3.org/TR/2007/CR-ws-policy-attach-20070330.
Vedamuthu, A. S., Orchard, D., Hirsch, F., Hondo, M., Yendluri, P., Boubez, T., and Ümit Yalçinalp (2007b). Web services policy 1.5 - framework.
http://www.w3.org/TR/2007/CR-ws-policy-20070330.