Implementação de mecanismos de privacidade no OpenID
Connect
Pedro Henrique Pereira Martins1∗, Rodrigo Duarte Lopez1†, Rafael Weingärtner1 ,
Jorge Werner1 , Carla Merkle Westphall1
1
Laboratório de Redes e Gerência
Universidade Federal de Santa Catarina (UFSC)
Caixa Postal 476 – 88.040-970 – Florianópolis – SC – Brasil
{pedro,rodrigo,weingartner,jorge,carla}@lrg.ufsc.br
Abstract. In cloud computing it is necessary to prevent data leakage that could
compromise the privacy of its users. Data stored by users on a cloud identity
provider must be stored using secure methods and the user must be aware of
the use of his data. This work aims to develop a way to prevent attackers or
administrators to have access to the cloud user data ensuring users’ privacy.
Our model proposes encryption of data stored on the identity provider as well
as request the user’s permission for the dissemination of his data, whenever data
is requested by any application. Thus, the user participates in the process as it
provides encryption/decryption keys and allows or not the release of data when
an application (service provider) requests data from the identity provider. The
proposals were implemented through an extension of MITREid software that is
an available implementation of OpenID Connect.
Resumo. Na computação em nuvem é necessário impedir o vazamento de dados
que possam comprometer a privacidade de seus usuários. Os dados guardados
pelos usuários em um provedor de identidade na nuvem devem ser armazenados usando métodos seguros e o usuário deve ter ciência sobre o uso dos seus
dados. Este trabalho tem como objetivo desenvolver uma maneira de impedir
que invasores/administradores tenham acesso aos dados dos usuários da nuvem garantindo a privacidade dos usuários. Nosso modelo propõe cifrar os
dados armazenados no provedor de identidades além de requisitar a permissão
do usuário para disseminação dos seus dados, sempre que estes forem requisitados por alguma aplicação. Dessa forma, o usuário participa do processo já
que fornece chaves de cifragem/decifragem e permite ou não a liberação dos
seus dados quando uma aplicação (provedor de serviço) requisita dados para
o provedor de identidade. As propostas foram implementadas através de uma
extensão do software MITREid que é uma implementação disponı́vel do OpenID
Connect.
1. Introdução
A computação em nuvem é um modelo ubı́quo, conveniente e de acesso compartilhado
a recursos computacionais como servidores e diferentes tipos de serviços. Este modelo
∗
†
Bolsista do CNPq - Brasil
Bolsista do CNPq - Brasil
também é capaz de fornecer e liberar recursos rapidamente com baixo custo de gestão
[Mell and Grance 2011].
A propagação das identidades e das informações pessoais chamadas PII (Personally Identifiable Information) deve ser controlada e monitorada de acordo com a
legislação. As informações sensı́veis como identidades de funcionários, ou ainda,
informações sobre estruturas organizacionais, serviços e aplicações de empresas, não podem ser expostas nos provedores de serviços nas nuvens [Weingärtner 2014].
A privacidade é um direito fundamental [Lauterpacht 1948] e deve ser garantido mesmo em ambientes online [Council 2012]. A melhoria da segurança e privacidade nos ambientes de computação em nuvem é fonte de pesquisas [Sánchez et al. 2012]
[Betgé-Brezetz et al. 2012] [Kalloniatis et al. 2014]. Há preocupação com a segurança
dos usuários para impedir o vazamento dos seus dados sensı́veis.
Para gerenciar as identidades de ambientes de computação em nuvem são usados
os sistemas de gerenciamento de identidades (IdM - Identity Management), que podem
ser definidos como frameworks capazes de administrar informações pessoais ligadas a
identidade do usuário [Bertino et al. 2009] [Hansen et al. 2008].
Uma federação é um conjunto de provedores de identidade (IdP - Identity Provider) e de serviço (SP - Service Provider) que estabelecem uma confiança mútua para
aceitar e confiar nos dados trocados entre esses provedores. Usando identidades federadas
usuários realizam a autenticação uma única vez no domı́nio de origem e podem acessar
recursos e serviços de múltiplos e diferentes domı́nios pertencentes à federação, já que
os participantes da federação confiam no resultado da autenticação feita pelos parceiros
[Orawiwattanakul et al. 2010] [Bertino and Takahashi 2011].
O gerenciamento de identidades na computação em nuvem precisa de garantia e transparência nas práticas de privacidade, no controle do uso e fluxo dos dados
[Weingärtner and Westphall 2014] [Santos et al. 2014]. Para isso, é necessário que mecanismos de privacidade presentes na autenticação e na autorização definam modelos e
polı́ticas de uso de atributos adequadas [Faraji et al. 2014] [Chadwick and Fatema 2012].
Nos sistemas de gerenciamento de identidade garantir a segurança de PIIs é um problema
quando se assume que existem administradores ou invasores maliciosos e/ou curiosos que
tem acesso aos PIIs dos clientes armazenados em um ambiente online de nuvem computacional.
Neste trabalho o objetivo principal foi a inserção de caracterı́sticas de privacidade
na versão MITREid [MIT 2014] que é uma implementação do sistema de gerenciamento
de identidades OpenID Connect [OpenID 2014], que não possuia controles de privacidade. O modelo proposto tem a etapa diferenciada no cadastro do usuário no provedor de
identidade e é fortemente centrado no usuário, já que precisa do consentimento e ciência
do próprio usuário para liberação de atributos para o provedor de serviço. Nesse sentido
este trabalho apresenta uma contribuição significativa pois estende o OpenID Connect
para melhorar a privacidade dos usuários.
O texto está organizado em 6 seções. Na seção 2 os trabalhos relacionados são
descritos. A seção 3 apresenta as ferramentas usadas no desenvolvimento. A seção 4
explica como a privacidade foi inserida no OpenID Connect. Na seção 5 a implementação
realizada é descrita e as conclusões sobre o trabalho estão na seção 6.
2. Trabalhos Relacionados
O trabalho de [Switch 2012] desenvolveu um plugin para o sistema Shibboleth que fornece ao usuário a ciência sobre a divulgação de dados repassados para um provedor de
serviço. Todos os usuários do ambiente usam a mesma polı́tica de liberação que é fixa no
sistema. Já no trabalho de [Orawiwattanakul et al. 2010] os usuários podem selecionar,
no sistema Shibboleth, entre todos os atributos não-obrigatórios que pretendam divulgar
ao SP que está sendo acessado. É um trabalho usado na federação japonesa GakuNin.
Em ambos trabalhos não há cifragem dos dados no provedor de identidade. Assim, um
administrador malicioso pode ter acesso aos dados existentes na base de dados do IdP.
O trabalho de [Sánchez et al. 2012] propõe um protocolo de reputação para o estabelecimento dinâmico de uma federação usando a reputação das entidades. Os usuários
podem verificar as reputações dos provedores da federação antes de enviar quaisquer dados aos provedores. O modelo propõe uma maneira de verificar o que está sendo feito
com os dados liberados e assim os próprios usuários aumentam ou diminuem a reputação
do provedor. Um protótipo usando o sistema Authentic para implementar o IdP que considera a reputação foi desenvolvido.
No artigo de [Betgé-Brezetz et al. 2012] é proposta uma maneira de definir se um
usuário confia ou não em um provedor de nuvem. Com base na confiança do provedor de
nuvem, o usuário pode enviar seus dados em texto plano, parcialmente criptografado (com
alguns metadados em texto plano) ou totalmente criptografado para a nuvem. Também foi
proposto o envelope de dados privados para transportar os dados dos usuários para a nuvem. Esse envelope pode conter os dados criptografados (ou não) com algumas polı́ticas
que declaram como, onde, por quem e quando esses dados podem ser usados.
3. Ferramentas utilizadas
No desenvolvimento do trabalho várias ferramentas foram estudadas e testadas: OpenId
Connect, Spring, CloudStack, Cryptico e Sjcl.
OpenId Connect [OpenID 2014]: O OpenId Connect é um sistema de gerenciamento de identidades que dispõe de implementações em diversas linguagens, mas tem
IdP e SP escritos em Java com boa documentação. O OpenId Connect funciona como
uma camada extra no protocolo OAuth2.0, permitindo que os usuários de serviços online
possam observar a identidade do servidor que está requisitando seus dados e saber quais
dados estão sendo requisitados pelo servidor, além de auxiliar na resolução de qual IdP
usar, usando como referência o nome/aplicação/endereço do IdP. Foi usada a MITREid
que é uma implementação do OpenId Connect feita pelo MIT [MIT 2014]. Na figura 1 é
representado o fluxo da interação entre usuário (browser), IdP e SP no OpenID Connect.
No passo 1 o usuário requisita acesso ao recurso protegido. No passo 2 o SP requisita
a autenticação do usuário que é realizada no passo 3. No passo 4 o usuário pode ter a
chance de consentir com a liberação de dados para o SP. No passo 5 o IdP envia a prova
da autenticação para o SP que é validada no passo 6. No passo 7 o SP obtém atributos do
usuário a partir do IdP para liberar ou não o acesso ao recurso no passo 8.
Spring [Spring 2015]: é um framework de desenvolvimento Java com várias bibliotecas. Foi usado o Spring para auxiliar na criação e gestão de objetos Java em memória.
Spring-MVC é uma parte do Spring que cuida da infraestrutura do código que foi usada
Figura 1. Fluxo da interação entre Usuário, IdP e SP no OpenID Connect
[Weingärtner 2014]
para separar a parte lógica da parte da interface do usuário. Spring-Web é uma parte
do Spring que cuida do mapeamento das páginas web que foi usada para mapear todas
as páginas utilizadas no projeto. Spring-Security [Spring 2015] é uma parte do Spring
que cuida dos aspectos de segurança da aplicação e foi usada para proteção de URL,
autenticação de usuário e redirecionamento de URL.
CloudStack [Apache 2015]: é uma ferramenta usada para gerenciar os dispositivos de hardware de uma ou mais máquinas para suportar a criação de máquinas virtuais
com uso dinâmico dos recursos e compatibilidade entre diferentes tipos de software. Cria
um ambiente do tipo IaaS (Infrastructure as a Service). Foi usada essa ferramenta para
criação de máquinas virtuais nas quais hospedamos as aplicações de IdP e SP usadas.
Cryptico [Terrell 2015]: é uma biblioteca de criptografia em JavaScript. Foi
usada para o desenvolvimento da cifragem dos dados do usuário usando o algoritmo
RSA para geração de par de chaves assimétricas com uma semente (seed) e cifragem/decifragem de dados usando criptografia assimétrica.
Sjcl [Stark et al. 2015]: é uma bibilioteca de criptografia em JavaScript que foi
usada para o cálculo do valor obtido com a função PBKDF2. O PBKDF2 é uma função
de derivação de chaves a partir de senhas, que usa um valor salt e repete o processo do
HMAC-SHA256 inúmeras vezes, resultando num valor mais seguro, porém mais custoso
também para ser gerado.
4. Extensão do OpenID Connect para melhoria da privacidade
Nossa proposta de extensão do OpenID Connect é fazer o usuário, dono dos seus dados,
participar de toda a interação feita entre o IdP e o SP. Essa extensão proposta foi desenvolvida em conjunto durante o trabalho de dissertação de mestrado de [Weingärtner 2014].
O modelo proposto está representado e explicado na figura 2, e demonstra todo o
fluxo na interação entre usuário, IdP e SP.
Figura 2. Fluxo da interação entre Usuário, IdP e SP no modelo proposto
No IdP o usuário cifra os dados a serem armazenados durante o processo de cadastro do usuário no provedor de identidade. No momento que a aplicação no provedor de
serviço precisa dos dados do usuário, é o próprio usuário que, com sua chave, irá decifrar
os dados necessários com a chave escolhida no cadastro, e então irá cifrar os dados novamente com uma chave de sessão que será enviada para o SP. No momento da decifragem
o usuário tem a chance de escolher qual o conjunto de atributos será decifrado. Assim,
o usuário escolhe e fica consciente sobre a disseminação dos seus dados. Foram criados
alguns tipos de conjuntos de dados: total e parcial. No conjunto total todos os dados do
usuário serão decifrados para serem disseminados. Já no conjunto parcial apenas alguns
dados escolhidos pelo usuário serão decifrados e disseminados para o SP.
Foi criada a possibilidade do provedor de serviço especificar um conjunto de dados (escopo) que será necessário para o funcionamento correto da aplicação. O IdP por
sua vez irá mapear esses escopos para os atributos correlacionados. Para isso, foram criadas algumas classes: SystemScopeDao que carrega da base de dados do IdP os escopos
selecionados; SystemScopeService que constrói o escopo em tempo de execução; LrgScopeClaimTranslationService que traduz os escopos carregados para tipos de atributos.
5. Resultados experimentais
Para adicionar nossas propostas ao protocolo padrão do OpenID Connect foi usada a
versão de código desenvolvida pelo MITRE chamada MITREid [MIT 2014]. Foi necessário realizar várias modificações nesse código do MITREid.
Primeiramente o código fonte da implementação do OpenID Connect feita pelo
MITRE foi obtido [MIT 2014]. Foram instaladas as aplicações OpenId Connect Spring
Server e Simple Web App do MITRE e foram feitos alguns testes. As seguintes
modificações iniciais foram feitas no código fonte obtido:
• Após testar a aplicação com o IdP do MIT e ver que tudo funcionou perfeitamente,
realizou-se testes com outro IdP, no caso, o IdP da Google. Então foi criado um
cadastro para a aplicação em questão no IdP da Google para esta poder fazer
requisições de autenticação e dados neste IdP. Logo de inı́cio foram encontrados
problemas de compatibilidade entre a aplicação e o IdP, pois a aplicação obtinha
o endereço do IdP através do protocolo WebFinger, que não é implementado pelo
IdP da Google. Assim, foi criada uma opção extra para que na hora de selecionar
o IdP, fosse possı́vel fornecer um recurso do IdP para o WebFinger resolver o
endereço do IdP. De outra forma o endereço do IdP é fornecido diretamente, para
resolver tais problemas, foi criada a página da figura 3.
• Foi testada a compatibilidade da aplicação com outros IdPs, no caso o IdP da
Google, então encontraram-se algumas inconsistências na implementação do protocolo pela parte do MITRE. Existia um atributo NONCE que sempre era requisitado pela aplicação, sendo que na especificação do protocolo, esse atributo poderia
ou não ser requisitado. A aplicação estava implementada para exigir esse atributo
por parte do IdP e o IdP da Google não fornece esse atributo. Com isso, modificamos as classes PlainAuthRequestUrlBuilder com a adição de um valor lógico
UseNonce para adicionar o campo do nonce ou não, na formação da URL, e na
classe OIDCAuthenticationFilter também foi colocado um UseNonce para que a
aplicação possa suportar o uso seletivo do NONCE. Depois que essas incompatibilidades foram acertadas a aplicação passou a funcionar corretamente para o IdP
da Google e do MITRE.
Foram criadas novas páginas web para a aplicação: página para seleção de IdP
para autenticação, página para cadastro de usuários e página para alteração dos dados
dos usuários. A criação de todas essas páginas envolveu a modificação do código da
plataforma OpenID Connect.
5.1. Seleção de IdP para autenticação
Nesta página web, apresentada na figura 3, o usuário irá definir qual IdP ele gostaria de
usar, informando o endereço do próprio IdP ou usando web-finger para fazer a resolução
automática do IdP através de um recurso.
Figura 3. Página web para seleção do IdP
5.2. Cadastro de usuários
Na página de cadastro, representada na figura 4, novos usuários irão fornecer seus dados para serem armazenados no banco de dados do IdP. Os campos para cadastro são:
nome de usuário para autenticação, senha para autenticação, nome, sobrenome, e-mail,
telefone, data de nascimento, gênero, cpf, rg, além de uma chave ou uma palavra passe
que o usuário irá fornecer para cifrar os dados do banco de dados do IdP. Após o usuário
entrar com todos os dados em seus respectivos campos, é enviado para o IdP os valores
calculados pelo PBKDF2 a partir da senha e dos dados do usuário, e, esses mesmos dados
(menos a senha) são cifrados usando a chave/palavra que o usuário escolheu e enviados
para o IdP. O salt usado no PBKDF2 é derivado do nome de usuário fornecido e também
é enviado para o IdP onde tudo é armazenado. A chave ou palavra passe não é enviada
para o IdP, apenas é usada na página e depois descartada.
Figura 4. Página web para cadastro no IdP
A figura 5 mostra a página gerada para retornar uma resposta para o usuário após
ele ter terminado de se cadastrar. É possı́vel verificar como os dados do usuário foram
persistidos no banco de dados em sua forma cifrada.
5.3. Disseminação dos dados do usuário para o SP
A página de disseminação de dados (figura 6) alerta o usuário dos perigos em relação
ao SP e os dados que o mesmo deseja obter. Nesta página, o usuário deve informar quais
dados deseja liberar para o SP. Selecionados os dados, o usuário deverá fornecer sua chave
ou palavra passe, para decifrar estes dados antes de enviá-los para o SP.
Para desenvolver nossa proposta de controle da disseminação foi necessário criar
um conjunto de classes para armazenar os dados temporariamente. A classe UserInfoTempController é responsável por receber uma requisição AJAX com os atributos selecionados que devem ser enviados ao SP e armazenar esses atributos utilizando o objeto chamado lrgUserInforTempService. Esse objeto lrgUserInforTempService deve ser injetado
Figura 5. Dados do usuário cifrados ao final do processo de cadastro
no userInfoUserDetailsService que é o objeto responsável por responder as requisições do
SP. Alterações no arquivo approve.jsp foram necessárias para possibilitar ao usuário escolher quais dados serão disseminados para o SP. Outra modificação realizada no arquivo
approve.jsp foi a adição de um filtro para interceptar todas as requisições que utilizam
este arquivo. Este filtro é responsável por carregar e definir no objeto requisitado todos
os metadados necessários para auxiliar o usuário durante o processo de disseminação de
dados ao SP. Todo processo de cifragem e definição de atributos a serem disseminados foi
uma extensão implementada no código original.
Figura 6. Processo de disseminação estendido
5.4. Alteração dos dados de usuário
A página web apresentada na figura 4 é usada para alterar os dados do usuário. O usuário,
após autenticado no IdP, pode alterar seus dados, inclusive a chave usada na cifragem.
Para fazer isso, o usuário irá acessar esse recurso, fornecer sua chave para abrir os dados,
ver qual dado ele quer trocar e alterar o dado. Para alterar a senha o usuário terá que
fornecer a senha antiga e a nova senha duas vezes. Feito isso, na hora de enviar as novas
informações para o IdP, toda a operação de cifrar e calcular os valores com o PBKDF2 é
feita novamente, como na página de cadastro, e então esses dados são alterados no banco
de dados.
6. Conclusão
Este trabalho de iniciação cientı́fica contribuiu na implementacao dos aspectos de privacidade propostos na dissertacao de mestrado de [Weingärtner 2014], já que existe uma
grande quantidade de classes e códigos presentes no sistema MITREid.
No desenvolvimento do trabalho foram criadas novas páginas para interação do
usuário com o IdP, foram criadas novas classes e modificadas classes existentes e também
foram feitos testes do funcionamento. O IdP foi preenchido com dados exemplo através
dessas páginas, e, depois, uma aplicação de testes foi desenvolvida para usar o IdP. Com
esta implementação todo usuário cadastrado no IdP tem seus dados cifrados antes da
persistência no banco de dados do IdP que está executando no ambiente de computação
em nuvem do LRG (Laboratório de Redes e Gerência) da UFSC. No momento que uma
aplicação requisita os dados do usuário, o IdP notifica o usuário a respeito dos dados
requisitados pela aplicação. O usuário então decifra estes dados com sua chave para fazer
a liberação desses dados para a aplicação. Para facilitar o processo de decifragem, o
usuário também pode optar por derivar um par de chaves a partir de uma palavra passe
(palavra que servirá como a senha): o usuário fornece a palavra/frase e o próprio sistema
deriva o par de chaves a ser usado para decifrar os dados.
Assim a decisão final de liberar ou não os dados para a aplicação é do usuário,
que está ciente a respeito de todo o processo. Essa foi uma grande modificação feita no
funcionamento do código MITREid do OpenId Connect.
Todo processo de cadastro, cifragem e definição de atributos a serem liberados foi
uma extensão implementada no código original. É importante observar que toda a parte
de criptografia adicionada gera um aumento no processamento e no espaço de armazenamento no banco de dados, mas é um acréscimo que garante a privacidade do usuário.
Questões de usabilidade da aplicação foram facilitadas com a possibilidade de derivação
de chaves com a entrada da palavra passe.
Com estas precauções no manejo dos dados entre IdP e SP há uma grande melhoria
na privacidade do usuário nesse ambiente de gerenciamento de identidades que pode ser
usado na nuvem. Diferente dos trabalhos [Switch 2012] [Orawiwattanakul et al. 2010],
que usam o sistema Shibboleth, o nosso trabalho garante a privacidade dos dados cadastrados no IdP e o usuário participa do processo de decifragem e disseminação dos
seus dados, usando o OpenID Connect. Semelhante aos trabalhos [Sánchez et al. 2012]
[Betgé-Brezetz et al. 2012], o nosso trabalho também é centrado no usuário, alerta os
usuários antes do envio dos dados ao provedor e desenvolveu um protótipo.
Referências
Apache (2015). Apache cloudstack. http://cloudstack.apache.org/.
Bertino, E., Paci, F., Ferrini, R., and Shang, N. (2009). Privacy-preserving digital identity
management for cloud computing. IEEE Data Eng. Bull., 32(1):21–27.
Bertino, E. and Takahashi, K. (2011). Identity Management: Concepts, Technologies, and
Systems. Artech House.
Betgé-Brezetz, S., Kamga, G.-B., Ghorbel, M., and Dupont, M.-P. (2012). Privacy control
in the cloud based on multilevel policy enforcement. In CLOUDNET 2012, pages 167–
169. IEEE.
Chadwick, D. W. and Fatema, K. (2012). A privacy preserving authorisation system for
the cloud. Journal of Computer and System Sciences, 78(5):1359–1373.
Council, H. R. (2012). The promotion, protection and enjoyment of human rights on the
internet (a/hrc/20/l.13). http://ap.ohchr.org/documents/alldocs.aspx?doc id=20280.
Faraji, M., Kang, J.-M., Bannazadeh, H., and Leon-Garcia, A. (2014). Identity access
management for multi-tier cloud infrastructures. In NOMS 2014, pages 1–9. IEEE.
Hansen, M., Schwartz, A., and Cooper, A. (2008). Privacy and identity management.
Security & Privacy, IEEE, 6(2):38–45.
Kalloniatis, C., Mouratidis, H., Vassilis, M., Islam, S., Gritzalis, S., and Kavakli, E.
(2014). Towards the design of secure and privacy-oriented information systems in the
cloud: Identifying the major concepts. Comp. Standards & Interfaces, 36(4):759–775.
Lauterpacht, H. (1948). The universal declaration of human rights. Brit. YB Int’l L.,
25:354.
Mell, P. and Grance, T. (2011). The nist definition of cloud computing. NIST.
MIT (2014). Mitreid connect. https://github.com/mitreid-connect/.
OpenID (2014). Welcome to openid connect. http://openid.net/connect/.
Orawiwattanakul, T., Yamaji, K., Nakamura, M., Kataoka, T., and Sonehara, N. (2010).
User-controlled privacy protection with attribute-filter mechanism for a federated sso
environment using shibboleth. In 3PGCIC, 2010 Int. Conf. on, pages 243–249. IEEE.
Sánchez, R., Almenares, F., Arias, P., Dı́az-Sánchez, D., and Marı́n, A. (2012). Enhancing
privacy and dynamic federation in idm for consumer cloud computing. IEEE Trans.
on Cons. Elec., 58(1):95–103.
Santos, D. R. D., Nascimento, T. J., Westphall, C. M., Leandro, M. A. P., and Westphall,
C. B. (2014). Privacy-preserving identity federations in the cloud: A proof of concept.
Int. J. Secur. Netw., 9(1):1–11.
Spring (2015). Spring framework. https://spring.io/.
Stark, E., Hamburg, M., and Boneh, D. (2015). Stanford javascript crypto library. Stanford University. https://github.com/bitwiseshiftleft/sjcl/tree/version-0.8.
Switch (2012). uapprove - user consent module for shibboleth identity providers.
https://www.switch.ch/aai/support/tools/uapprove/.
Terrell, R. (2015). Cryptico library. https://github.com/wwwtyro/cryptico.
Weingärtner, R. (2014). Controle de disseminação de dados sensı́veis em ambientes federados. Master’s thesis, UFSC, Florianópolis, Brasil.
Weingärtner, R. and Westphall, C. M. (2014). Enhancing privacy on identity providers. In
2014 The Eighth International Conference on Emerging Security Information, Systems
and Technologies (SECURWARE), pages 82–88, Lisbon, Portugal.