Embed Size (px)
Citation preview
JOHNATHAN DOUGLAS DE SOUZA SANTOS
LUIZ FELIPE NEITZKE ALVES
PEDRO DE SOUZA NANDI
ANÁLISE SOBRE A TECNOLOGIA OPENID SOB OS ASPECTOS DE
ARQUITETURA, ABORDAGENS E SOLUÇÕES
JOINVILLE - SC
2013
UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS - CCT
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO - DCC
JOHNATHAN DOUGLAS DE SOUZA SANTOS
LUIZ FELIPE NEITZKE ALVES
PEDRO DE SOUZA NANDI
ANÁLISE SOBRE A TECNOLOGIA OPENID SOB OS ASPECTOS DE
ARQUITETURA, ABORDAGENS E SOLUÇÕES
Trabalho extra classe apresentado a disciplina de Segurança em Redes de Computadores do curso de Ciência da Computação do Centro de Ciências Tecnológicas da Universidade do Estado de Santa Catarina.
Professor: Charles Christian Miers
JOINVILLE - SC
2013
LISTA DE ILUSTRAÇÕES
Figura 1: Modelo básico de um sistema SSO ............................................................................11
Figura 2: Arquitetura inicial utilizando SSO ................................................................................12
Figura 3: Arquitetura mais robusta e complexa utilizando SSO .................................................13
Figura 4: Funcionamento básico da tecnologia OpenID ............................................................15
Figura 5: Diagrama de sequência de um processo de autenticação via OpenID .......................19
Figura 6: Exemplo de utilização do selo de autenticação do Yahoo! .........................................28
Figura 7: Comparação entre os diagramas dos processos de autenticação do Kerberos e do
OpenID ......................................................................................................................................37
LISTA DE TABELAS
Tabela 1: Exemplo de um processo de autenticação via OpenID ..............................................18
Tabela 2: Comparação entre as abordagens usuais de OpenID, considerando segurança e
facilidade de implementação .....................................................................................................22
Tabela 3: Classificação de benefícios e limitações do OpenID vistos os critérios de análise
apresentados no capítulo 4 .......................................................................................................39
LISTA DE ABREVIATURAS
SSO Single Sign-On URL Uniform Resource Locator XRI Extensible Resource Identifier FAP Federated Authentication Provider
SUMÁRIO
1 INTRODUÇÃO .....................................................................................................................6
2 CONCEITOS ........................................................................................................................8
2.1 SISTEMA DE AUTENTICAÇÃO ....................................................................................8
2.2 AUTENTICAÇÃO SINGLE SIGN-ON ..........................................................................10
2.3 CONCEITO E HISTÓRICO DO OPENID .....................................................................13
2.4 CONSIDERAÇÕES PARCIAIS ...................................................................................16
3 OPENID .............................................................................................................................17
3.1 TERMINOLOGIA .........................................................................................................17
3.2 ARQUITETURA E FUNCIONAMENTO .......................................................................18
3.2.1 Processos de Autenticação ...............................................................................18
3.3 PRINCIPAIS ABORDAGENS ......................................................................................20
3.4 PROBLEMAS DE AUTENTICAÇÃO ...........................................................................24
3.5 SEGURANÇA..............................................................................................................25
3.5.1 Usuário Malicioso ...............................................................................................25
3.5.2 RP Malicioso .......................................................................................................27
3.6 PROJETOS RELACIONADOS ....................................................................................29
3.6.1 Shibboleth...........................................................................................................29
3.6.2 Windows Card Space .........................................................................................30
3.7 CONSIDERAÇÕES PARCIAIS ...................................................................................31
4 ANÁLISE ............................................................................................................................32
4.1 CASOS COMENTADOS .............................................................................................32
4.2 ANÁLISE DO OPENID ................................................................................................33
4.2.1 Arquitetura ..........................................................................................................33
4.2.2 Abordagens ........................................................................................................35
4.2.3 Soluções .............................................................................................................37
4.3 CONSIDERAÇÕES PARCIAIS ...................................................................................39
5 CONSIDERAÇÕES FINAIS................................................................................................40
6 REFERÊNCIAS ..................................................................................................................41
6
1 INTRODUÇÃO
No mercado atual, é possível encontrar várias soluções relacionadas a métodos
de autenticação. Autenticar é nada mais que garantir que uma pessoa realmente seja
quem ela diz ser, porém a verificação de identidades tem papel fundamental na
computação e na segurança da informação. A disciplina de Segurança em Redes de
Computadores tem como um de seus objetivos garantir que informações sejam
disponibilizadas apenas para quem as têm direito de acesso, o que inclui: técnicas de
criptografia, prevenção e combate contra ameaças de códigos maliciosos, proteção de
hosts em geral e mensagens oriundas de atacantes e, claro, controle de acesso dos
usuários. Caso um atacante tenha acesso a uma conta de um determinado serviço ou a
informações importantes de algum usuário, isto é considerado uma invasão de
privacidade e, automaticamente, torna-se uma violação dos pilares da segurança da
informação.
Este trabalho tem como objetivo analisar o OpenID, uma tecnologia de
autenticação de usuários em sistemas diversos. O protocolo OpenID é uma solução
aberta que provê ao usuário um login único e permite a autenticação em diferentes
websites e serviços, onde ambos compartilham da mesma OpenID. O funcionamento
do OpenID é baseado em um padrão para autenticar a identidade do usuário a partir de
uma URL (Uniform Resource Locator) ou XRI (Extensible Resource Identifier), que
pode ser verificada por qualquer servidor que suporte o protocolo. Este protocolo,
desenvolvido originalmente em 2005, vem sendo amplamente estudado e aprimorado
por representantes de grandes empresas que atuam na Internet (Google, PayPal,
Facebook, etc.), além de pesquisadores do âmbito acadêmico e diversos colaboradores
de comunidades open source. O objetivo da tecnologia OpenID reflete o crescente
número de aplicações que adentram ao mercado atualmente e que apresentam focos
específicos e necessidades de um serviço de autenticação. Com o crescente
desenvolvimento da Internet, torna-se importante o conhecimento desta tecnologia,
vistas as facilidades que esta pode proporcionar aos seus utilizadores.
Esta análise do OpenID tem como foco principal três aspectos do protocolo: sua
arquitetura, principais abordagens e as soluções em segurança oferecidas pelo mesmo.
7
Para tal fim, faz-se necessário descrever em detalhe o funcionamento do protocolo, e
também decorrer sobre sistemas de autenticação num geral. Assim, este trabalho
encontra-se dividido da seguinte maneira:
1. Levantamento bibliográfico e fundamentação teórica de conceitos
fundamentais em autenticação. Dentre esses conceitos, decorre-se sobre
os fatores de autenticação, a definição de Single Sign-On, e a origem e
histórico do OpenID enquanto sistema de autenticação.
2. Revisão bibliográfica aprofundada sobre o funcionamento do OpenID.
Inclui o processo de autenticação, arquitetura, abordagens, problemas de
autenticação, e questões de segurança.
3. Análise do OpenID, usando os fundamentos apresentados como base
para decorrer sobre os aspectos de arquitetura, abordagens e soluções,
além da apresentação de casos comentados de empresas que tiveram
resultados satisfatórios com a opção pelo OpenID.
Espera-se que este trabalho sirva como introdução à tecnologia do OpenID.
Também espera-se que com a análise realizada, torne-se mais fácil tomar um decisão
sobre a adoção ou não do OpenID, e que possam ser feitos comparativos sobre
tecnologias de autenticação similares usando este trabalho como base.
8
2 CONCEITOS
Este capítulo apresenta conceitos fundamentais para o desenvolvimento deste
trabalho. As seções do capítulo lidam, respectivamente, com os temas de sistemas de
autenticação, do conceito de autenticação Single Sign-On, e de uma breve introdução
ao OpenID e seu histórico. O entendimento destes conceitos é de grande utilidade
antes do aprofundamento sobre o funcionamento do OpenID no capítulo 3, uma vez
que uma introdução sobre a tecnologia permite uma melhor contextualização do tema.
No entanto, essa introdução não seria suficiente para um entendimento adequado do
conteúdo deste trabalho.
O OpenID é uma solução baseada no conceito de Single Sign-On, logo coloca-
se uma definição deste conceito e explica-se qual a finalidade de uma solução que se
encaixa neste conceito. Similarmente, apresenta-se o que são e para que serve os
sistemas de autenticação, visto que o OpenID é justamente uma tecnologia para
autenticação de usuários em sistemas. Uma vez colocados estes conceitos, o leitor
deve ser capaz de entender as características essenciais de um sistema de
autenticação Single Sign-On, e assim melhor visualizar a aplicação e o funcionamento
do OpenID no decorrer deste trabalho.
2.1 SISTEMA DE AUTENTICAÇÃO
Autenticação é a capacidade de garantir que um usuário é de fato quem ele diz
ser. Em um sistema computacional, a autenticação pode transcorrer em níveis distintos,
seja separada ou em conjunto. Dentre os principais tipos de autenticação estão
(GALVÃO, 2005):
Autenticação do Usuário: Procura distinguir um indivíduo dos outros, seja por
características físicas, algo que ele possua ou saiba;
Autenticação do Parceiro de Comunicação: São utilizados outros mecanismos de
autenticação para assegurar a origem da comunicação;
9
Autenticação da Mensagem: Os dados transmitidos passam por um processo de
verificação para validar sua autenticidade.
A autenticação do usuário recebe um destaque dentre os demais itens e
costuma receber ênfase em relação à segurança nas infraestruturas web, visto a
disponibilidade de realizá-la remotamente (GUIMARÃES, 2006). A categoria de
autenticação do usuário é subdividida em três fatores (GALVÃO, 2005):
―O que o usuário sabe‖ – Prova por conhecimento: É um sistema caracterizado
por algo que somente o usuário conhece como, por exemplo, sua senha;
―O que o usuário possui‖ – Prova por posse: É um sistema que necessita de algo
físico como cartões magnéticos, smart-cards ou tokens;
―O que o usuário é‖ – Prova por biometria: É um sistema que procura autenticar
o usuário através de algo que o torne único como, por exemplo, sua impressão
digital.
Os aspectos levantados por Galvão (2005) permitem a autenticação de um
usuário a partir do conhecimento, posse ou biometria. Cada segmento está atrelado a
circunstância na qual é empregado. Por exemplo: a utilização de biometria ou posses
físicas para autenticação do usuário em sites cotidianos (e-mail, redes sociais, blogs,
etc.) é inviável, pois nem todos os dispositivos de acesso possuem tais recursos de
verificação. Neste contexto, a autenticação mais utilizada é via prova por conhecimento
(autenticação do usuário através de senhas). Apesar dos vários meios de autenticação
disponíveis, é preciso identificar se o aspecto desejado pode ser empregado na
identificação do usuário em relação a sua utilização.
Segundo Guimarães (2006), dentre os aspectos descritos acima, o mais
empregado e conhecido é o da autenticação de usuários via senhas. Visto que os
usuários podem especificar senhas fracas e até mesmo esquecê-las (o que faz com
que muitos as anotem em algum lugar), a autenticação via senhas não é das mais
10
seguras (GUIMARÃES, 2006). Analisando tais fatos, os sistemas de autenticação
apresentam alguns desafios (GALVÃO, 2005):
Coletar dados do usuário para autenticação;
Fazer a transmissão destes dados de forma segura;
Saber se o usuário que está se autenticando realmente é quem diz ser;
Provar que o usuário se autenticou no sistema.
Os desafios citados resultam no pilar da segurança da informação, descrito na
norma ISO/IEC 17799 de 2005. A norma recomenda a manutenção de requisitos como:
confidencialidade, disponibilidade, irretratabilidade e integridade. Os requisitos orientam
a análise, o planejamento e a implementação da segurança para um determinado grupo
de informações que se deseja proteger. O objetivo é reduzir os riscos ou mantê-los
dentro dos limites aceitáveis, economizar dinheiro através de ações preventivas e
definir rotas alternativas quando possíveis incidentes ocorrerem. Embora existam tais
desafios a serem superados, existem várias soluções para autenticação, que vão desde
as mais seguras até as mais utilizadas, e que irão depender de seus níveis de
usabilidade e necessidade para serem empregadas. Pode-se citar como solução de
autenticação, o Identity Metasystem (JONES, 2006), o Smart Card (CHIEN et. al, 2002)
e o Windows Card Space (CHAPPEL, 2006).
2.2 AUTENTICAÇÃO SINGLE SIGN-ON
Segundo Wang et al. (2011), o maior número de aplicações web que aparecem
na Internet implica em mais contas individuais para acesso do usuário a seus serviços.
Porém, é notório que autenticação do usuário via senha possui vulnerabilidades em
relação aos ataques de phishing1 (roubo de informação). Logo, para mitigar este
problema, cada página deveria ter uma conta distinta, tornando-se um desafio para o
1 Phishing: É um tipo de ataque virtual em que vítimas possuem suas informações pessoais ou
credenciais roubadas por páginas ou e-mails fraudulentos (KUMARAGURU et al, 2006). Phishers podem agir configurando sites falsos que pareçam confiáveis para induzir as vítimas a revelarem seus logins e senhas.
11
usuário ter que se lembrar de todas as suas senhas, caracterizando a chamada ―fadiga
de senhas‖ (BELLAMY-MCINTYRE et al., 2011).
Para You e Zhu (2012), mesmo múltiplos sistemas em um mesmo departamento
ou empresa normalmente utilizam serviços de autenticação de identidade distintos, o
que acarreta dificuldades, pois os usuários devem lembrar múltiplas contas e senhas. O
gerenciamento tende a se tornar tedioso, ter sua eficiência reduzida (pois cada login
acarreta um novo processo de autenticação) e ocupar muitos recursos do sistema,
além do risco de vazamento das credenciais de login do usuário. Segundo os autores, a
tecnologia de Single Sign-On2 (SSO) apresenta-se como forma efetiva para resolver
estes problemas, pois os usuários apenas tomam a iniciativa de autenticação por rede
uma única vez e os recursos autorizados serão então disponibilizados sem a
necessidade de mais um processo de autenticação. A figura 1 mostra um exemplo de
um sistema SSO simples.
Figura 1: Modelo básico de um sistema SSO.
Fonte: PEIXOTO, 2012.
A figura 1 mostra o exemplo de um usuário fazendo um único login que autentica
o mesmo e libera acesso a múltiplos aplicativos. Esta é exatamente a função do
método SSO. Assim, pode-se definir, segundo Peixoto (2012), o método de
autenticação Single Sign-On como o aproveitamento do acesso identificado de
2 Single Sign-On: (SSO) Significa literalmente ―único acesso‖. É o conceito de que uma única
autenticação provenha acesso a múltiplos serviços.
12
usuários. Isso vale para qualquer sistema que possua acesso controlado, seja ele
protegido por qualquer um dos fatores de segurança - ―O que o usuário é‖, ―O que o
usuário possui‖ e ―O que o usuário sabe‖.
Peixoto (2012) ressalta que o método SSO é bastante estudado na disciplina de
Gerenciamento de Acesso e Identidades, como sendo uma boa solução para
segurança segundo requisitos funcionais, operacionais e de negócio no que se diz
respeito aos elementos do ciclo de vida de um usuário (autenticação no sistema,
autorização de acesso e auditoria dos acessos). Outra utilidade inerente ao uso do
SSO é a flexibilidade do acesso do usuário quando se trata de um portal de serviços,
por exemplo, onde o usuário migra entre os serviços oferecidos em uma única sessão.
Neste trabalho, é adotada a definição de Peixoto (2012), pois o mesmo
determina claramente que o método SSO é um conceito sobre acesso aproveitado de
um usuário a serviços integrados e não uma tecnologia própria. Tal entendimento é
necessário, já que o OpenID possui fundamentação conceitual em SSO.
O método SSO é uma tecnologia que vem sendo recomendada e adotada por
vários especialistas em TI, porém, apesar do número de protocolos existentes, não é
uma solução perfeita. Segundo Zhao et al. (2004), uma abordagem ingênua na
implantação de um sistema SSO pode acarretar riscos significativos a segurança, como
ilustrados nas figuras 2 e 3.
Figura 2: Arquitetura inicial utilizando SSO.
Adaptado de: ZHAO et al., 2004.
13
Figura 3: Arquitetura mais robusta e complexa utilizando SSO.
Adaptado de: ZHAO et al., 2004.
A figura 2 apresenta um sistema simples que utiliza SSO. Enquanto isso, a figura
3 mostra uma arquitetura que resolve alguns dos problemas do modelo anterior (figura
2), porém é mais complexo que o anterior, o que evidencia a necessidade de certa
análise e projeto de uma arquitetura condizente com as necessidades do contexto.
Além da arquitetura, também é importante observar outros aspectos da implementação
como, por exemplo, a tecnologia empregada.
2.3 CONCEITO E HISTÓRICO DO OPENID
Segundo Recordon e Reed (2006), o OpenID 1.0 foi originalmente concebido por
Brad Fitzpatrick, arquiteto chefe da empresa Six Apart e atualmente, encontra-se em
sua versão 2.0 estável. O OpenID é uma tecnologia distribuída baseada no método de
autenticação Single Sign-On para a Internet que possibilita a autenticação
descentralizada de seus usuários (Jeng, 2012). A tecnologia OpenID é empregada por
uma grande quantidade de páginas e serviços na Internet atualmente, principalmente
por aqueles que possuem conteúdos exclusivos para usuários cadastrados.
Conforme Assis (2010), a popularização da Internet a partir da segunda metade
da década de 1990 fez com que um grande número de serviços comerciais migrasse
14
para a web. Grande parte dos serviços que começaram a ser oferecidos através da
Internet começou a requisitar algum nível de autenticação para seus usuários, e a
maneira encontrada para viabilizar tal autenticação foi através do uso de logins e
senhas.
Esta abordagem, além de autenticar a identidade do usuário, possibilita uma
estrutura de níveis de acesso, podendo ser aplicada com diversas finalidades como
acesso a conteúdos e serviços exclusivos, por exemplo. Porém, devido à rápida
evolução da Internet comercial, houve uma extrapolação na quantidade de páginas e
serviços requisitando autenticação de usuários via logins e senhas. Este fenômeno,
segundo Recordon e Reed (2006), foi o principal motivador para o desenvolvimento da
tecnologia OpenID.
A tecnologia OpenID surgiu como uma ferramenta de integração para os
serviços de autenticação disponíveis. De acordo com OpenID Foundation (2007), a
autenticação via OpenID provê uma maneira de provar que um usuário final possui uma
identidade através de uma URL (Uniform Resource Locator), ou seja, a partir do
momento que o usuário realiza o seu cadastro em uma página que utiliza a tecnologia
OpenID (esta página é chamada de fornecedora), ao acessar outras páginas e serviços
na Internet que utilizem também OpenID e requeiram autenticação, posteriormente, ele
poderá autenticar-se informando apenas o endereço (URL) da página fornecedora,
onde realizou seu primeiro cadastro. A figura 4 exemplifica o funcionamento básico do
OpenID em um processo de autenticação via senhas.
15
Figura 4: Funcionamento básico da tecnologia OpenID.
Fonte: Elaboração dos autores. Adaptado de ASSIS, 2010.
Na figura 4, o usuário faz sua autenticação na página do serviço requisitado
utilizando seu login e senha OpenID – caso o usuário já tenha feito login utilizando
OpenID em outro serviço, utilizará apenas a URL fornecedora. O serviço deve então
consultar provedores OpenID para validar a identidade do usuário. Mais detalhes sobre
o funcionamento da arquitetura do OpenID serão apresentados nos capítulos 2 e 3.
De acordo com Assis (2010), o OpenID diferencia-se de outras tecnologias que
utilizam o método de autenticação Single Sign-On justamente por não especificar o
mecanismo de autenticação. Dessa maneira, o usuário não precisa informar seus
dados e demais informações que não deseja sempre que precisar se autenticar, ou se
cadastrar em algum novo serviço na Internet. Segundo a OpenID Foundation (2013),
empresas como Google, Yahoo, Live Journal, Flickr, Wordpress e AOL utilizam a
tecnologia OpenID em suas redes de serviços disponibilizados através da Internet.
Segundo Wang (2012), a praticidade provida pelo OpenID na autenticação Single Sign-
On via URL da página fornecedora (sem necessidade de informar dados de
autenticação mais de uma vez) é o ponto principal que o diferencia de seus
concorrentes.
16
2.4 CONSIDERAÇÕES PARCIAIS
No capítulo 1, são apresentados os conceitos fundamentais para o
desenvolvimento deste trabalho. Para possibilitar o conhecimento básico sobre o que é
o OpenID e qual é sua proposta, é necessária uma introdução sobre os problemas
relacionados a autenticação na Internet, atualmente. Este é o objetivo do capítulo 1,
abrangendo os conceitos de sistemas de autenticação e Single Sign-On, que são peças
fundamentais no conceito da tecnologia OpenID.
No capítulo 2, a tecnologia OpenID é abordada de forma profunda,
apresentando-se sua arquitetura, funcionamento e debatendo problemas de
autenticação e aspectos de segurança. O capítulo 2 será necessário para a
compreensão do funcionamento e dos conceitos que envolvem a tecnologia OpenID.
17
3 OPENID
Segundo Jeng (2012), o OpenID é um padrão aberto de tecnologia distribuída
que permite autenticação descentralizada aos seus usuários. O OpenID é considerado
uma das implementações pioneiras de Single Sign-On (SSO) para web e, conforme
Ionita (2012), em Dezembro de 2009 já contava com cerca de 1 bilhão de contas ativas
distribuídas em aproximadamente 9 milhões de sites em toda a Internet. Tais números,
tão expressivos, explicam-se devido as grandes corporações (Google, Yahoo, AOL,
etc), e seus usuários ativos, que adotaram o uso do OpenID a partir de sua criação, em
2005. Atualmente em sua versão 2.0, é gerenciado por um comitê que envolve a
participação de grandes empresas e entidades de pesquisa (Wang, 2012).
Neste capítulo, são apresentados os conceitos gerais do OpenID. Junto com
suas funcionalidades, é possível ter a noção sobre os objetivos desta tecnologia . Além
deste início conceitual, são apresentadas também algumas vulnerabilidades do OpenID
em segurança que, por consequência, são as causas dos problemas de autenticação
que também serão apresentados.
3.1 TERMINOLOGIA
De acordo com Assis (2010) e Sovis et al. (2010), para melhor compreensão da
arquitetura e do funcionamento do OpenID, são necessárias as identificações dos
seguintes agentes:
Usuário: Composto pelo usuário final e seu terminal, que executa um software
(navegador) com acesso a Internet. Através do navegador, o usuário final
consegue acessar páginas e serviços que requisitam autenticação e assim,
quando possível, ele pode utilizar sua identidade OpenID;
Provedor de Identidade OpenID (IdP): Servidor que armazena informações
necessárias relativas aos usuários e responsável por garantir a autenticação dos
mesmos em múltiplos serviços e aplicações. O IdP é o fornecedor da identidade
OpenID do usuário;
18
Relying Parties (RP): Página ou serviço online que provê, em sua própria
estrutura de autenticação, a opção de autenticação através de identidades
OpenID aos seus usuários.
Os agentes possuem um papel fundamental na arquitetura do sistema,
proporcionando identificar o papel e a responsabilidades de cada item. A relação entre
eles é direta, o que implica na necessidade dos serviços estarem disponíveis para que
o funcionamento do sistema transcorra de maneira consistente.
3.2 ARQUITETURA E FUNCIONAMENTO
Segundo Wang (2012), o ponto chave da arquitetura do OpenID, que o diferencia
das demais soluções baseadas em SSO para web, é o fato dos provedores de
identidade serem únicos e distribuídos. Isto faz com que os usuários sejam livres para
escolher o provedor que desejarem. O protocolo de funcionamento não prevê nenhum
tipo de relação prévia entre IdPs e RPs para realizar as autenticações. Esta seção
apresenta o funcionamento e os componentes que moldam o OpenID.
3.2.1 Processos de Autenticação
Conforme Assis (2010) e Wang (2012), é possível exemplificar um processo de
autenticação via OpenID através da cronologia apresentada na tabela 1 e na figura 5:
Tabela 1: Exemplo de um processo de autenticação via OpenID.
Cronologia Descrição do Ato
A O usuário escolhe um IdP e requisita uma identidade.
B
O IdP provê ao usuário uma identidade. Esta identidade é composta
por uma URL única. A partir desta etapa, o usuário poderá se
autenticar em múltiplos RPs utilizando esta identidade (conta).
C O usuário então deseja se autenticar em um RP utilizando sua conta
OpenID. Para isso, ele entrega sua identidade OpenID (URL) ao RP.
D
Com o URL, o RP extrai um documento XML chamado XRDS
(Extensible Resource Descriptor Sequence) que armazena
informações sobre a localização do IdP do usuário na Internet.
19
E
Após identificar o IdP do usuário, o RP estabelece uma conexão com
o mesmo para definir uma chave de segurança compartilhada. Esta
chave será utilizada na verificação de mensagens reebidas
diretamente do usuário. Segundo Ionita (2012), essas chaves são
distribuídas através de um mecanismo baseado método de
distribuição Diffie-Hellman.
F
Em seguida, o RP estabelece uma conexão entre o navegador do
usuário e a página de autenticação do seu IdP. Nesta etapa, o
usuário é notificado sobre a integridade do RP e, em seguida,
questionado pelo seu Idp sobre tal integridade.
G
Caso o usuário confirme a integridade do RP, o IdP irá enviar a
confirmação da autenticação para o RP e redirecionar a conexão
com o usuário para o RP.
H A partir disso, o usuário pode navegar normalmente sem necessitar
validar sua conta com seu IdP novamente.
Fonte: Elaborado pelos autores.
Figura 5: Diagrama de sequência de um processo de autenticação via OpenID.
Fonte: Elaborado pelos autores.
20
A tabela 1 e a figura 5 mostram como a autenticação ocorre, através de uma
interação entre o usuário, o IdP e o RP, para garantir a identidade do usuário. Este
método de autenticação faz com que os RPs necessitem apenas de informações
realmente necessárias sobre os usuários para realizar a autenticação dos mesmos em
seus sistemas. Segundo Wang (2012), isso faz com que o processo de autenticação
seja mais direto e eficiente para ambas as partes, além do que, o usuário ganha mais
privacidade perante o RP. Ionita (2012) faz lembrar que o processo de autenticação
através de identidades OpenID depende fundamentalmente da disponibilidade do IdP
do usuário.
O método utiliza um conjunto de dados mínimos para realizar a autenticação dos
usuários, além de proporcionar uma maior eficácia no processo de autenticação. Como
benefício, o grau de privacidade do usuário é elevado em relação ao RP permitindo que
este possa navegar livremente com apenas uma validação com o IdP, evitando a
repetição dos usuários no preenchimento de logins e senhas.
3.3 PRINCIPAIS ABORDAGENS
Enquanto tecnologia para a implementação de SSO e gerenciamento de
identidades, o OpenID pode ser descrito como uma solução focada no usuário e não
focada no site ou no serviço (BELLAMY-MCINTYRE et al., 2011). Uma característica
que separa o OpenID de outras implementações SSO é que o provedor de identidade
não precisa ter relação prévia com a página ou servidor para que está provendo
autenticação, sendo necessário apenas uma identidade OpenID (URL) por parte do
usuário (WANG, 2012).
Segundo Bellamy-McIntyre et al. (2011), o protocolo OpenID é complexo e
possui apenas uma especificação textual, o que aumenta a dificuldade de se garantir
que uma implementação qualquer não contenha falhas de segurança. Algumas
abordagens já foram propostas e tiveram bons resultados, sendo até aplicadas no meio
empresarial. Estas abordagens propõem modelos funcionais e melhorias na segurança,
servindo como ponto de partida para uma implementação que atenda às necessidades
da empresa sem prejudicar as atividades da mesma:
21
Abordagem Padrão: Zhao et al. (2004) elaboram sobre design de sistemas SSO
usando uma implementação padrão em OpenID como exemplo, contendo um
provedor de autenticação, clientes e RPs que requerem acesso autenticado. Os
usuários tentam acessar um serviço em um RP que redireciona o usuário para
se autenticar no provedor. Após inserir seu nome de usuário e senha para fazer
login no provedor, o mesmo redireciona o usuário de volta ao RP com acesso
liberado ao que lhe compete. Um servidor de certificados garante uma operação
mais segura por meio de assinaturas nas requisições, porém esta arquitetura
não é suficiente para garantir uma autenticação segura;
Autenticação via One-Time Password (OTP): Segundo Wang et al. (2011), OTP
são senhas geradas por fatores estáticos e dinâmicos, computadas por um
determinado algoritmo e somente podem ser usadas uma vez. Após o login, o
provedor requer a OTP do cliente e somente conclui a autenticação caso a
senha esteja correta. Esta abordagem é destacada como a mais segura, pois
apenas o provedor e o cliente conhecem o algoritmo exato para geração da
senha única;
Autenticação usando OpenID e OAuth3: De acordo com Chu et al. (2010),
embora ambas tecnologias de Single Sign-On distintas, tanto OpenID quanto
OAuth são abertas e não-excludentes. Chu et al. (2010), afirmam que a
autenticação do OAuth se dá pela concessão de um token de autorização ao
cliente e o processo ocorre sem que o RP receba as credenciais do cliente em
momento algum, algo que aumenta a confidencialidade da transação. Para a
implementação desta abordagem, o provedor OpenID e o provedor OAuth
devem ser o mesmo, e o RP também assume o papel de consumidor do token
de autorização toda vez que uma requisição a um serviço for feita. A Google
especificou uma abordagem semelhante que também combina OpenID e OAuth
(BALFANZ et al., 2007);
3 OAuth é um padrão aberto para autorização que fornece um meio de clientes acessarem os recursos
do servidor em nome do proprietário de um recurso (como um cliente diferente ou um usuário final). O OAuth encontra-se atualmente em sua versão 2.0. (RFC 6749, 2012)
22
Solução Federada: Embora seja uma tecnologia mais focada no usuário do que
nos serviços (BELLAMY-MCINTYRE et al., 2011), o OpenID é bastante flexível e
também pode ser utilizado para gerenciar federações de parceiros em ambientes
colaborativos. Watanabe e Tanaka (2009) sugerem, por exemplo, um protocolo
que faz uso de um FAP4, e que utiliza autenticação normal via OpenID e a
garantia de uma ID única enviada via celular para liberação de recursos
compartilhados.
Para melhor efeito de comparação envolvendo as principais características de
cada abordagem, a tabela 2 fornece mais informações. A tabela 2 apresenta uma
comparação envolvendo critérios como: versatilidade, facilidade de implementação e
capacidade de autenticação multi-fator.
Tabela 2: Comparação entre as abordagens usuais de OpenID, considerando
segurança e facilidade de implementação.
Abordagem Autenticação
Multi-Fator Facilidade de
Implementação Versatilidade
Abordagem Padrão
Não Simples Bastante versátil. Em
especial para sistemas menores
Autenticação via OTP
Sim. O que o usuário sabe (senha) e o que
possui (OTP)
Simples, exceto pela criação de um bom
algoritmo para geração de OTP
O uso de OTP é mais indicado em
sistemas com maiores riscos de
segurança
Autenticação via OpenID e OAuth
Sim. O que o usuário sabe (senha) e o que possui (token OAuth)
Razoável. São tecnologias
compatíveis, porém distintas
O uso de tokens de acesso limitado é mais comum em
sistemas web (Chu et al., 2010)
Solução Federada
Sim. No caso do protocolo que usa o
FAP, ocorre com o uso da senha e da ID do
celular do usuário
Depende do que se deseja. O uso do
celular como no FAP é mais complexo
Somente para entidades federadas
Fonte: Elaborada pelos autores.
4 Federated Authentication Provider (FAP): É um provedor específico para autenticação em entidades
federadas.
23
Como é possível analisar na tabela 2, uma abordagem padrão, por ser mais
simples que as demais, apresenta-se mais versátil. Porém, as demais abordagens (via
OTP, via OpenID e OAuth, e federada), devido a suas maiores complexidades, são
voltadas para cenários mais específicos, com aplicações mais direcionadas.
A grande flexibilidade e facilidade de implementação do OpenID foram razões
que contribuíram para sua grande aceitação no mercado e é possível combinar
autenticação por OpenID com outras técnicas de gestão de identidades ou segurança.
Bellamy-McIntyre et al. (2011), sugerem uma cuidadosa modelagem do processo de
Single Sign-On a ser implementado. Para isso, dividem o campo de modelagem em:
―Modelagem sob a perspectiva do usuário‖ e ―Modelagem sob a perspectiva do
sistema‖. Segundo os autores, a perspectiva do usuário tornam claros os diagramas de
uso do sistema e como ocorre a comunicação. Porém é uma visão mais abstrata e que
omite detalhes mais específicos da implementação.
Com o uso de uma modelagem apropriada do Single Sign-On antes da
implementação, é possível identificar facilmente vulnerabilidades em relação a
possíveis ataques como o phishing (roubo de informação), no caso da perspectiva do
usuário, ou ataques como man-in-the-middle5 (ataques de interceptação de
informação), no caso da perspectiva do sistema.
Conhecendo o funcionamento do protocolo OpenID e sendo capaz de modelar e
estudar a abordagem de implementação mais adequada para determinada finalidade, é
possível obter-se uma noção da arquitetura funcional de Single Sign-On. No entanto,
não são somente questões de implementação que caracterizam as vulnerabilidades no
uso de OpenID, mas sim até os arquivos de configuração do provedor podem trazer
falhas exploráveis por um atacante. Uma abordagem consistente e uma modelagem do
processo de autenticação resultam em menos preocupações, porém todo cuidado é
pouco quando a questão é a segurança da informação.
5 Man-in-the-middle (Homem-no-meio) é um ataque que intercepta a comunicação entre duas partes
para a manipulação e/ou captura de dados.
24
3.4 PROBLEMAS DE AUTENTICAÇÃO
Segundo Oh e Jin (2008), o OpenID é um framework livre, aberto e
descentralizado para gestão de identidades digitais com foco no usuário. O SSO provê
a autenticação conveniente, caso o usuário deseje receber um serviço de outro RP que
tenha suporte ao OpenID. Tal conveniência ocorre pelo canal entre o RP e o provedor,
sem necessidade de nova autenticação pelo usuário, que deve apenas informar sua
OpenID. Porém, existem algumas características na autenticação do OpenID que
podem influenciar negativamente a segurança da aplicação final. De forma a descrever
algumas dessas características, cita-se o experimento realizado por Oh e Jin (2008),
sobre as regras de provedores OpenID e como um atacante pode se valer delas para
acessar recursos de sistema que não cabem a ele.
Uma vulnerabilidade de autenticação que pode ocorrer se dá pelo fato do
OpenID ser uma solução baseada em cookies que utiliza criptografia simétrica, menos
segura que a assimétrica (OH e JIN, 2008). Segundo a OpenID Foundation (2006), os
provedores OpenID em geral fazem uso do algoritmo AES-128 ou AES-256 para cifrar
as mensagens. Além disso, o OpenID faz uso do protocolo HTTPS durante a
autenticação e, durante este processo, usa duas chaves de sessão para promover uma
transação mais segura (OpenID FOUNDATION, 2006). Porém, mesmo com o uso do
HTTPS, existe uma diferença entre o estado de autenticação do usuário no provedor,
que dura uma sessão, e o estado no RP, que pode durar um tempo mais longo antes
de expirar, fato que permite o ataque documentado por Oh e Jin (2008).
Segundo os autores, mesmo que a autenticação no provedor expire, o estado de
autenticação ainda é válido nos RPs que receberam o token de confirmação de
autenticação. Além disso, todo URL de OpenID possui um nonce, cuja função é ser
uma chave criptográfica que funciona apenas uma vez (ROGAWAY, 2004). O nonce
deveria contribuir para a segurança da autenticação, mas segundo a especificação
padrão do OpenID, o nonce não precisa ser assinado, apenas válido segundo a
verificação de integridade do RP (OpenID FOUNDATION, 2006). Desta forma, fazendo
uso de dois browsers ao mesmo tempo, foi possível obter um nonce válido em um
25
browser e usá-lo no lugar do nonce original no outro browser, obtendo assim acesso
não autorizado aos recursos do serviço, mesmo após o encerramento da sessão.
De acordo com Oh e Jin (2008), existem mais vulnerabilidades de autenticação
no OpenID por se tratar de uma solução ampla, genérica e, sobretudo, distribuída. Isto
torna ainda mais difícil a garantia de requisitos de segurança. Apesar das
vulnerabilidades do OpenID, a OpenID Foundation vem buscando meios de impedir que
um atacante possa se valer das mesmas para acessar recursos do sistema dos quais
ele não tem permissão de acesso. Partindo disso, uma análise da segurança do
sistema é apresentada na seção 3.5.
3.5 SEGURANÇA
Esta seção analisa os problemas de segurança que podem ser encontrados no
OpenID. Considerando três cenários diferentes no qual cada cenário um agente tenta
violar a segurança de diferentes formas. No decorrer da seção são propostas possíveis
soluções ou prevenções para evitar os ataques referentes a cada cenário.
3.5.1 Usuário Malicioso
No processo de autenticação, o usuário envia para o RP um identificador
OpenID, uma URL. Este identificador requer um campo de texto onde o usuário pode
digitar qualquer URL e, assim, forçar o RP a acessar uma página especificada por ele.
Diante deste aspecto, um usuário malicioso pode, segundo Charas (2009):
Acessar um host interno no RP: Caso um usuário insira a uma URL como, por
exemplo, ―localhost/admin.php?action=sql&query=DROP TABLE user‖, o
servidor do RP acessaria a si próprio através de uma requisição HTTP. Esta é
uma falha grave, considerando que a maioria dos servidores investe pouco em
medidas de segurança contra conexões locais;
Forçar acesso a hosts externos: Um usuário malicioso pode forçar o RP a
acessar outros hosts. Ao inserir um endereço como, por exemplo,
“www.exemplo.com/falhadeseguranca.php?attack=true‖, o usuário pode
26
responsabilizar o RP por um determinado ataque através de uma falha de
segurança descoberta por ele;
Causar inundação (overflow): O usuário malicioso pode causar inundação,
enviando para o RP uma grande quantidade de dados. Ao inserir uma URL
como, por exemplo, "www.exemplo.com/arquivo.bin”, onde ―arquivo.bin” é um
arquivo muito grande, o usuário causará uma situação que poderá ser
interpretada como ataque.
Causar negação de serviço: Este tipo de ataque é caracterizado por inundar o
servidor com mais pedidos do que ele pode processar, deixando-o indisponível.
Uma maneira de realizar este tipo de ataque é enviando um grande número de
pedidos de autenticação ao RP. Neste caso, o usuário insere uma URL para
autenticação, o que faz com que o RP entre em contato com o provedor OpenID
para que o mesmo inicie o processo de verificação da identidade. Porém, o
usuário prossegue, enviando pedidos de autenticação antes que o provedor
OpenID possa retornar a resposta para o RP quanto o sucesso da autenticação.
Este processo acaba inundando o servidor do RP, fazendo com que em
determinado momento ele comece a descartar os pedidos, o que caracteriza a
negação de serviço.
Os ataques citados relatam uma série de ataques que, por sua vez, são
relativamente simples de serem executados. Os usuários maliciosos podem cometer
tais tipos de ataques quando o sistema não apresentar mecanismos para evitar ou
mesmo dificultar a ação destes indivíduos.
Segundo Feld e Pohlmann (2010), o RP pode utilizar-se de filtros para conter
usuários maliciosos, limitando o que pode ser inserido no campo de identificação. O
filtro deve banir hosts que entrem repetidamente com identificadores que não passam
pelo processo de descoberta e deve também desabilitar endereços que levem o RP a
conectar-se a hosts internos. Além disso, o RP deve também banir hosts que façam
muitos pedidos de autenticação em um curto período de tempo, evitando assim
inundações e falhas por negação de serviços (CHARAS, 2009).
27
A utilização de filtros, o ato de banir os hosts com ações indevidas dentre outras
medidas, amplifica a dificuldade ou até mesmo inibe a ação de um usuário malicioso.
Isso dificulta a prática dos ataques, o nível de segurança do sistema é elevado e ele se
torna mais confiável.
3.5.2 RP Malicioso
Uma grave ameaça de segurança está relacionada ao RP malicioso. Neste caso,
ao invés de redirecionar o usuário para seu provedor OpenID, como ocorre no processo
de autenticação, o RP redireciona o usuário para uma outra página (CHARAS, 2009).
A identificação do provedor do usuário no RP ocorre através da URL inserida por
ele, que redireciona o RP para uma página semelhante à página do provedor na qual o
usuário está acostumado a autenticar-se. Se o provedor OpenID do usuário
utiliza nome de usuário e senha como método de autenticação, e o usuário não
percebe que está em uma outra página, ele pode acabar inserindo suas informações de
autenticação no falso provedor e, assim, disponibilizando suas credenciais para o RP
malicioso (FELD; POHLMANN, 2010).
O ataque é conhecido como phishing, um método de roubo de identidade online
que pode ser bastante difícil para um usuário final identificar. A maneira mais eficaz de
detectar o phishing é analisando a URL para qual o usuário é redirecionado, pois esta
costuma ser a característica mais difícil de falsificar (FELD; POHLMANN, 2010). O
phishing é um problema de segurança que pode atingir tanto o usuário quanto o
provedor OpenID comprometendo a confiança do consumidor (CHARAS, 2009).
Como se pode identificar o phishing através da URL, é recomendado que o
usuário verifique com atenção a URL do provedor OpenID e confirme que ela de fato
está de acordo com a URL original antes de inserir os dados para sua autenticação. Se
a URL parecer suspeita, é possível que o RP esteja tentando executar um ataque de
phishing (CHARAS, 2009). Uma prevenção é utilizar complementos do navegador que
auxiliam na detecção deste tipo de ataque como, por exemplo, o Netcraft (extensão
disponível para Firefox e Chrome). Outra medida possível é utilizar a versão mais
recente dos navegadores, pois já possuem de forma integrada as proteções contra anti-
28
phishing. Em geral, estes complementos utilizam a mesma técnica de forma a
aconselhar o usuário a verificar a URL (FELD; POHLMANN, 2010).
Uma solução para o provedor é a criação de uma página de autenticação de fácil
reconhecimento para os usuários, mas que, ao mesmo tempo, seja difícil de ser
copiada em um ataque de phishing. Um exemplo interessante, e eficaz no mercado
atualmente, é o selo de autenticação da Yahoo!. O selo de autenticação, mostrado na
figura 6, consiste em uma pequena imagem ou texto. O usuário deve criar um selo para
cada computador que use (não esta vinculado a ID da Yahoo!, mas sim ao computador
do usuário), evitando criá-los em computadores compartilhados (YAHOO! INC., 2013).
Este selo será apresentado na tela do usuário antes que ele insira seus dados de
autenticação (FELD e POHLMANN, 2010). Se seu selo de autenticidade não for
exibido, trata-se, provavelmente, de uma página falsa.
Figura 6: Exemplo de utilização do selo de autenticação do Yahoo!.
Fonte: CHARAS, 2009.
Em geral, este tipo de selo é armazenado através de um cookie, e uma
característica importante dos cookies é que eles só podem ser acessados pelo domínio
que os criou (YAHOO! INC., 2013). Desta forma, um RP malicioso não pode ter acesso
ao selo utilizado pelo usuário e, consequentemente, não pode mostrá-lo na tela. Se o
usuário não ver seu selo ao acessar a página de autenticação, ele poderá atentar a
29
possibilidade de estar em uma página falsa, evitando, assim, inserir seus dados até que
se confirme a razão para que seu selo não tenha sido apresentado.
3.6 PROJETOS RELACIONADOS
Com o avanço da Internet, o aumento de provedores de serviços e a crescente
necessidade de compartilhar recursos para usuários de diferentes organizações que
possuam algum tipo de relação são fatores que motivam a constituição de federações.
Uma federação é uma forma de associação de parceiros de uma rede colaborativa que
usa um conjunto comum de atributos, práticas e políticas para trocar informações e
compartilhar serviços, possibilitando a cooperação e transações entre os membros da
federação (CARMODY et al. 2005).
O gerenciamento de identidades federadas, baseado nestes acordos comerciais,
técnicos e políticos, permite que as organizações de uma federação interajam entre si
com base na gestão da identidade compartilhada (IBM, 2005). Existem várias soluções
que fornecem o gerenciamento de identidades federadas como, por exemplo, o
Shibboleth (seção 3.6.1), OpenID e o Microsoft CardSpace (seção 3.6.2).
3.6.1 Shibboleth
O projeto Shibboleth (SHIBBOLETH CONSORTIUM, 2013) foi uma iniciativa do
consórcio americano Internet2 que teve como principal objetivo lançar uma
implementação de código aberto baseada em padrões abertos para tratar de desafios
relacionados ao gerenciamento de identidades e controle de acesso em instituições
acadêmicas. O Shibboleth é uma solução genérica para o gerenciamento de
identidades federadas, podendo ser adotada por qualquer tipo de organização.
O pacote de software desenvolvido está fundamentado sobre padrões abertos
como o XML e Security Assertion Markup Language (SAML) e provê uma forma fácil
para que aplicações web utilizem das facilidades providas pelo modelo de identidades
federadas como o conceito de autenticação única (SSO) e a troca segura de atributos
dos usuários por todos provedores de serviços que compõem a federação (WANGHAM
et al., 2010). O Shibboleth tem como ênfase a privacidade dos atributos dos usuários
sendo que, a liberação desses atributos para os provedores de serviços está
30
condicionada a política de privacidade da instituição de origem do usuário e também as
preferências pessoais deste usuário (SHIBBOLETH CONSORTIUM, 2013).
No Shibboleth, há dois papéis em destaque: o provedor de identidades (IdP) e o
provedor de serviços (SP). O primeiro é responsável por autenticar seus usuários,
antes que estes possam usufruir dos serviços oferecidos pelo segundo. O ponto
comum entre estes papéis é que ambos devem implementar toda a pilha de software
fornecida pelo projeto Shibboleth, permitindo assim o transporte das credenciais dos
usuários do provedor de identidades até o provedor de serviços (SHIBBOLETH
CONSORTIUM, 2013). No Shibboleth, o processo de autenticação sempre é executado
na instituição de origem do usuário, através de seu provedor de identidades, fazendo
uso dos mecanismos de autenticação presentes nessa instituição. A autenticação de
usuários pode ser feita através de nome de usuário e senha (CHADWICK, 2009). De
forma geral, o Shibboleth permite que sites possam tomar decisões de autorização para
o acesso individual dos recursos on-line de forma a preservar a privacidade dos
usuários.
3.6.2 Windows Card Space
Segundo Chappel (2006), nos diferentes tipos de redes colaborativas que
utilizam a Internet, diferentes tipos de identidades digitais são necessários e a realidade
é que estas identidades são providas por diferentes fontes (IdPs). Isto significa que a
solução para o gerenciamento destas identidades é utilizar sistemas que suportem
múltiplas identidades, ou seja, um ―sistema de sistemas‖ (meta sistema) focado na
identidade.
Os desafios são: criar, usar, e gerenciar esta diversidade de identidades de uma
forma efetiva. O Windows Card Space, originalmente chamado de InfoCard, é um
componente da plataforma .Net da Microsoft projetado para oferecer aos usuários uma
experiência consistente do uso de múltiplas identidades digitais, a partir do uso de um
agente especializado (MALER; REED, 2008). A tecnologia Card Space está disponível
por padrão nas versões sucessoras do MS-Windows Vista e pode ser incorporado em
versões anteriores do sistema operacional MS-Windows. Além disso, a mesma também
é suportada no navegador Internet Explorer, a partir da versão 7.0 (CHAPPEL, 2006).
31
O Card Space concentra-se nas coleções de dados do usuário chamados
cartões de informação (InfoCards), apresentados em uma interface de software
chamada ―seletor de identidade‖ (semelhante a uma carteira que contém os cartões
que identificam o usuário). No seletor de identidade, cada InfoCard representa uma
identidade diferente. Quando uma parte confiante (SP) solicita as credenciais do
usuário, este escolhe, a partir do seletor, uma de suas identidades (MALER; REED,
2008).
O Windows Card Space é uma solução SSO e sua abordagem está centrada na
identidade, no gerenciamento de identidades. A ideia consiste em um software cliente
responsável por fazer com que o usuário forneça sua identidade digital através da
escolha de cartões de um modo simples e seguro. Esta abordagem é conhecida como
―Seletor de Identidade‖. Desta forma, a Microsoft apresenta uma proposta de
autenticação para sites e serviços web.
3.7 CONSIDERAÇÕES PARCIAIS
Para possibilitar a compreensão geral do OpenID, é necessário o conhecimento
das terminologias envolvidas, da arquitetura e do funcionamento do mesmo. A partir do
estudo realizado, é possível identificar alguns benefícios, como: na arquitetura, quando
os usuários têm a liberdade de escolher o provedor que desejarem, no acolhimento
desta abordagem por parte das instituições, vista a flexibilidade de implementação, etc.
No entanto, a solução SSO pioneira apresenta alguns problemas de autenticação
como, por exemplo, ser uma solução baseada em cookies que utiliza criptografia
simétrica, possibilitando vulnerabilidades no sistema que comprometem a segurança,
seja através de usuário malicioso (negação de serviço) ou RP malicioso (phishing). De
forma geral, o OpenID é uma solução SSO que vem ganhando espaço e sofrendo
melhorias já que um grande número de empresas estão envolvidas na utilização desta
abordagem.
32
4 ANÁLISE
Com base no referencial teórico apresentado sobre os fundamentos da
autenticação Single Sign-On e na pesquisa bibliográfica sobre o funcionamento do
OpenID (sua arquitetura, abordagens e vulnerabilidades), foram elucidados vários
conceitos necessários para o entendimento geral necessário. Agora, utilizando estes
conceitos, este capítulo apresenta uma análise do OpenID segundo os aspectos de
arquitetura, abordagens e soluções.
São apresentados, neste capítulo, casos comentados sobre implementações do
OpenID em alguns RPs, provendo uma visão um pouco mais prática dos resultados
obtidos na adoção do OpenID como uma solução em autenticação. Também é
apresentada uma análise sobre a tecnologia OpenID em si.
4.1 CASOS COMENTADOS
Esta seção utiliza como exemplo soluções baseadas em OpenID da empresa
Janrain Inc. A Janrain foi fundada em 2005 (mesmo ano do lançamento da primeira
versão do OpenID) e tornou-se bastante ativa dentro da comunidade OpenID, estando
envolvida, também, na criação da OpenID Foundation. A Janrain fundou, também, em
2006 o MyOpenID.com que até hoje é um dos maiores provedores OpenID
independentes em atividade. Em 2008, a Janrain lançou o Janrain Engage
(anteriormente chamado de RPX), que é uma solução OpenID de Software as a Service
(SaaS), ou seja, uma solução que permite a websites o registro e a autenticação de
seus usuários através de contas de provedores como: Facebook, Google, Yahoo, AOL,
MySpace, Windows Live ID e Twitter.
Um dos clientes de maior destaque da Janrain é a Samsung, que incorporou a
plataforma JUMP (Janrain User Management Platform) ao seu website para facilitar o
cadastro de clientes em sua página, aumentar a participação no website e coletar
dados dos perfis dos usuários registrados para um melhor relacionamento com os
mesmos. De acordo com o departamento de marketing digital da Samsung, os
resultados foram melhores que o esperado. Inclusive, o mesmo departamento informou
que, os clientes que optaram por autenticação via redes sociais, possuem perfis
33
engajados ao website e, portanto, são mais valiosos para a empresa (JANRAIN INC.,
2012).
Outro cliente de destaque da Janrain é a Sulit, uma empresa de classificados e
e-commerce das Filipinas. A necessidade de implementação de um serviço SSO para
esta empresa surgiu visando facilitar o processo de registro de usuários em seu portal,
além de evitar a chamada ―fadiga de senhas‖ de seus clientes. Segundo a equipe
técnica responsável pelo website da Sulit, houve tentativas de desenvolvimento próprio
de uma solução OpenID por certo tempo, porém devido às diferentes implementações
dos IdPs (além das diferentes versões dos padrões, uma vez que nem todos os
provedores se atualizam quando os padrões são atualizados), os projetos não lograram
êxito. Por fim, a empresa optou por contratar a solução RPX da Janrain e os resultados
obtidos foram substanciais. Uma taxa de 15% dos cadastros no portal passaram a ser
realizados pelo RPX e houve uma redução de 50% no número de requisições de
recuperação de credenciais de acesso por parte de clientes já cadastrados (JANRAIN
INC., 2012).
4.2 ANÁLISE DO OPENID
A análise do OpenID nesta seção é dividida em três subseções, cada uma
focada em um critério específico. A primeira análise será voltada a arquitetura do
sistema de autenticação do OpenID, um aspecto primário que impacta diretamente na
complexidade e robustez do protocolo. Em seguida, serão analisados critérios
relacionados às abordagens conhecidas, citando as apresentadas na seção 2.3 e
também, outras tecnologias com escopos e soluções similares, onde são analisadas as
implementações em OpenID enquanto soluções para a autenticação em sistemas
diversificados.
4.2.1 Arquitetura
A arquitetura do OpenID é bastante simples. Esse é, talvez, o ponto mais forte
desta tecnologia. Seus elementos essenciais são os três agentes já mencionados: o
usuário, que faz acesso a um serviço através de um navegador web em um dispositivo
computacional qualquer; o IdP, responsável por armazenar dados dos usuários e
34
garantir a autenticação dos mesmos; e o RP, serviço que permite a autenticação de
usuários via OpenID. A autenticação ocorre mesmo sem qualquer relação prévia entre
estes três agentes citados, o que reforça o conceito de independência mútua. É uma
arquitetura extremamente simples e funcional que visa permitir uma gerência de
identidades descentralizada e focada nos usuários.
Segundo Recordon e Reed (2006), o foco principal da plataforma do OpenID é a
escolha do usuário. São, então, colocados três pontos fundamentais de liberdade de
escolha:
Escolha de endereços digitais: o OpenID, em sua última versão, não apenas
possibilita que usuários escolham entre múltiplos formatos de endereços digitais,
mas também que possam controlá-los e gerenciá-los, utilizando interfaces
simples via web;
Escolha dos provedores de identidade: Conforme já mencionado, o usuário é
livre para escolher o provedor de sua preferência para ser responsável pela
autenticação. Isto ocorre devido ao framework OpenID, desenvolvido de forma
em que o endereço digital e os dados para identificação de um usuário sejam
portáveis entre IdPs distintos;
Escolha dos provedores de serviços: De acordo com o modelo original do
OpenID, segundo Recordon e Reed (2006), o usuário não é limitado ao uso de
serviços suportados pelo seu IdP. Desta forma, o usuário tem a liberdade de
acessar novos serviços assim que os mesmos estiverem disponíveis, além de
migrar entre provedores concorrentes de um mesmo serviço com o mínimo
possível de interrupções no uso deste serviço.
Considerando tal aspecto de liberdade de escolha dada ao usuário, é possível
analisar que o OpenID é corretamente projetado para este fim, graças ao seu modelo
descentralizado que permite, inclusive, que um usuário opere seu próprio IdP.
Entretanto, esta análise da arquitetura do OpenID não se limita à visão da tecnologia
segundo seus desenvolvedores, mas também à visão do OpenID como uma solução
confiável para a segurança da identidade de seus usuários. Logo, esta análise é focada
35
na robustez da arquitetura, a fim de garantir a disponibilidade da comunicação entre o
usuário, o RP e o IdP.
Quanto a robustez, a arquitetura do OpenID está bem consolidada. As razões
para isso são explicáveis: o acoplamento entre os agentes (RP e IdP) é muito baixo e,
sem necessidade de estabelecimento de relações prévias no momento em que um RP
for considerado ineficaz, malicioso ou, simplesmente, obsoleto, o usuário pode passar a
usar outro RP que disponibilize o mesmo serviço ou um serviço semelhante. De forma
análoga, caso o IdP apresente problemas ao usuário como lentidão ou incapacidade de
autenticação, o usuário pode migrar para outro provedor de identidade de sua escolha
que não apresente tais problemas.
Uma vez que o OpenID foi desenvolvido desta maneira, com um grande foco no
usuário, a migração entre provedores de entidades e serviços distintos é rápida. Isto
torna a arquitetura simples do OpenID o seu ponto forte, pois quanto mais eficiente esta
migração ocorrer, maior será a disponibilidade do sistema. Uma arquitetura que facilite
a disponibilidade, conceitualmente, é uma arquitetura mais segura.
4.2.2 Abordagens
O OpenID, por definição, é uma solução genérica. Logo, pode ser utilizada de
formas diferentes e implementada conforme as necessidades dos usuários como, por
exemplo, as indicadas na seção 2.3 e, com isso, torna-se muito versátil. Entretanto, faz-
se necessária uma análise crítica do OpenID em relação às suas abordagens de
implementação, uma vez que os benefícios do uso dessa tecnologia somente são
relevantes se for viável a sua implementação.
As abordagens mais comuns encontradas na literatura e citadas na seção 2.3 –
abordagem padrão, autenticação via OTP, autenticação usando OpenID e OAuth e
solução federada – possuem um grande número de aplicações e de possíveis
extensões, embora não sirvam para todo tipo de sistema e não sejam soluções únicas
para estes problemas. Por exemplo, o Shibboleth é uma alternativa mais robusta,
tratando-se de entidades federadas, devido ao fato de ser um software aberto ao invés
de ser apenas uma especificação para autenticação. Além disso, o Shibboleth possui
36
foco na privacidade acima das escolhas dos usuários, o que pode ser preferível em
determinados casos.
Outro exemplo é o protocolo Kerberos, desenvolvido pelo MIT e que opera
através de tickets, ou seja, tokens especiais que também permitem a autenticação
multi-fator (NEUMAN; TS’O, 94). O Kerberos tem evoluído através da Microsoft, que o
adotou como método de autenticação padrão no MS Windows na forma chamada de
Microsoft Kerberos (MSDN LIBRARY, 2013). Efetivamente, o Kerberos serve ao
mesmo propósito do OpenID com OAuth, embora seja um projeto mais maduro
(publicado originalmente na RFC 1510, em 1993, e já se encontra em sua quinta
versão) e extensivamente utilizado. Trata-se de uma solução aberta disponível online,
além de ser oferecido comercialmente por empresas que ofereçam suporte
personalizado. Com tais características, o Kerberos torna-se uma alternativa para
algumas empresas devido à ampla documentação e ao suporte disponível. A figura 7
ilustra a diferença entre o funcionamento padrão de ambos os protocolos (Kerberos e
OpenID).
Figura 7: Comparação entre os diagramas dos processos de autenticação do Kerberos
e do OpenID.
Adaptado de: Ahmad et al., 2010.
37
Como ilustrado na figura 7, mesmo com uma extensão utilizando o OAuth para
gerar tokens para as autenticações, a abordagem do Kerberos já foi construída com
essa finalidade e, por isso, se mostra mais simples e funcional, uma vez que o OpenID
é inteiramente genérico e o Kerberos não. Assim, torna-se claro que há uma
compensação entre uma implementação genérica, embora sendo mais complexa, e
uma implementação específica para uma finalidade, realizada com eficiência.
A análise das abordagens do OpenID deve considerar a questão da
documentação. Este é um ponto em que o OpenID peca. Segundo Bellamy-McIntyre et
al. (2011), a implementação do OpenID é considerada não-trivial e passível de
ambiguidades, o que pode resultar em implementações existentes contendo falhas de
segurança. Embora sua arquitetura seja simples e fácil de entender, o protocolo
OpenID é complexo, e sua melhor referência é apenas uma especificação textual em
um documento mantido por uma comunidade (OPENID FOUNDATION, 2006).
4.2.3 Soluções
O OpenID está em constante evolução e aprimoramento. Este é um fator
positivo, pois significa que quanto mais esta tecnologia é estudada, falhas são
encontradas e, por consequência, provedores são notificados e aplicam as correções
necessárias, o que aumenta a segurança de toda a estrutura de autenticação. Porém, a
questão principal é: falhas de segurança ainda são falhas e falhas não devem ser
toleradas quando se trata de segurança da informação. Empresas como a Google e o
Facebook possuem milhões de acessos diários e vários serviços utilizam seus
provedores OpenID para autenticação, logo, uma falha de segurança pode significar um
número exorbitante de usuários em risco.
Esta análise do OpenID é baseada nos bons resultados que as grandes
empresas associadas aos comitês da OpenID Foundation (entre elas: Microsoft,
Google, Yahoo!, Facebook, PayPal e Symantec) têm obtido em seus serviços
prestados na web. Embora o OpenID seja, atualmente, considerado seguro e, devido
isso, tenha recebido tanta atenção na forma de pesquisas aplicação, ainda existe um
longo caminho a ser percorrido em relação a soluções altamente seguras. Wang et al.
38
(2012), exploram de maneira bastante interessante as vulnerabilidades existentes no
OpenID.
Duas vulnerabilidades principais são relatadas por Wang et al. (2012). Na
primeira, um atacante consegue forjar um requisição OpenID que não peça o e-mail do
usuário, e depois insere um e-mail não assinado na resposta do IdP. Caso o RP que
recebe a resposta não verifique que o e-mail não está assinado, essa página pode
acabar autenticando o atacante em qualquer conta local, como no caso de algumas
páginas como, por exemplo, Yahoo! Mail e Smartsheet.com. Segundo Wang et al.
(2012), todas as partes foram devidamente notificadas e corrigiram as vulnerabilidades
apresentadas. A segunda vulnerabilidade ocorre devido ao código vulnerável que
acaba por confundir tipos de dados nos campos da requisição e autenticar um atacante
nas contas no RP das vítimas. As empresas Google e PayPal confirmaram esta
vulnerabilidade em seus sistemas e, em seguida, corrigiram suas implementações.
Um aspecto de maturidade do OpenID que pode ser observado em Wang et al.
(2012) é: mesmo grandes empresas com vários profissionais responsáveis por
implementar o OpenID não estão imunes a vulnerabilidades triviais. Existem vários
fatores a serem considerados quando uma empresa estiver interessada em utilizar uma
solução OpenID. Um dos fatores diz respeito a vulnerabilidade do OpenID quanto ao
phishing devido a RPs maliciosos (SUN et al., 2011; OH; JIN, 2008). A única real
solução existente para este caso é recomendar fortemente aos usuários que prestem
atenção aos endereços de acesso dos serviços aos quais utilizam. Para uma tecnologia
bastante utilizada atualmente, este é um ponto fraco expressivo.
É possível notar que novas melhorias no OpenID, naturalmente, ainda surgirão
para torná-lo mais seguro e eficaz. Esta evolução tende a beneficiar os usuários de
maneira geral, seja no ramo comercial ou acadêmico. Porém, ao passo que novas
melhorias são desenvolvidas, mais ameaças surgem e, possivelmente, novas
vulnerabilidades são expostas e tornam-se alvo de tais ameaças. Como ciclo natural de
desenvolvimento e evolução da tecnologia, cabe aos desenvolvedores do OpenID
manter um nivelamento saudável entre estes dois extremos.
39
4.3 CONSIDERAÇÕES PARCIAIS
Conforme a seção 4.2, que apresenta a análise da tecnologia OpenID em vista
de sua arquitetura, de possíveis abordagens e soluções, é possível elaborar um resumo
dos principais pontos consolidados. A tabela 3 apresenta considerações sobre estes
principais pontos referentes à tecnologia OpenID, classificando-os como benefícios e
limitações.
Tabela 3: Classificação de benefícios e limitações do OpenID vistos os critérios de
análise apresentados no capítulo 4.
Benefícios Limitações
Arquitetura simples, versátil e robusta. Implementação passível de ambiguidades
que não é trivial.
Solução genérica, vistas as várias
possíveis abordagens de implementação
diferentes.
Documentação limitada.
Independência mútua entre componentes
arquiteturais.
Não é altamente seguro caso a
implementação não for cuidadosa ou o
provedor confiável.
Tecnologia em constante evolução. Ainda possui certas vulnerabilidades
exploráveis.
Gerenciamento fácil e prático por parte
dos usuários e administradores.
Fonte: Elaboração dos autores.
40
5 CONSIDERAÇÕES FINAIS
A arquitetura do OpenID, simples como é demonstrada, traz consigo significativa
robustez se tratando da disponibilidade do sistema. As abordagens padrão do OpenID
mostram-se bastante diversificadas e eficazes, apesar de sofrerem forte competição
vinda de tecnologias mais maduras e de propósitos específicos, como esperado para
uma solução genérica. A falta de uma documentação além da especificação padrão do
protocolo torna sua implementação mais difícil. Falhas de segurança existem, embora
raras, e evidenciam como algumas questões triviais podem gerar grandes
consequências caso a implementação não transcorra de maneira cuidadosa.
Com base nesta análise, pode-se concluir que o OpenID possui prognósticos
positivos para futuras melhorias e otimizações. Sua arquitetura simples e a
versatilidade na escolha do provedor para realizar autenticação justificam sua
considerável popularidade e grande adesão como protocolo de autenticação, mesmo
com menos de 10 anos de atuação no mercado. É importante frisar que o OpenID está
longe de ser considerado uma tecnologia consolidada. Sua última versão oficial foi
lançada da em 2007 e, desde então, foram várias as alterações na especificação
padrão (melhorias e correções) do projeto para tentar sanar as vulnerabilidades
encontradas e tentar proteger o mesmo contra as ameaças detectadas. Ou seja, esta
solução de código aberto tem potencial de melhora.
Do ponto de vista empreendedor, o OpenID é nada menos que uma revolução,
pois caracteriza-se solução open source que compete contra outras tecnologias já
existentes no mercado há muito mais tempo e seu potencial para expansão e robustez
são bastante palpáveis. A OpenID Foundation e seus colaboradores têm, para esta
tecnologia, o objetivo de tentar torná-la o padrão definitivo para autenticação SSO.
41
6 REFERÊNCIAS
AHMAD, Z.; MANAN, J. A.; SULAIMAN, S. Trusted Computing based open environment user authentication model. Anais...: 2010 3RD INTERNATIONAL
CONFERENCE ON ADVANCED COMPUTER THEORY AND ENGINEERING (ICACTE). 2010.
ASSIS, V. M. DE. Sistema de Identificação OpenID. Trabalho de Conclusão de
Curso. Rio de Janeiro: Universidade Federal do Rio de Janeiro, 2010.
BALFANZ, D. et al. OpenID OAuth Extension. Disponível em: <http://step2.googlecod
e.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html>. Acesso em: 7 mai. 2013.
BELLAMY-MCINTYRE, J.; LUTERROTH, C.; WEBER, G. OpenID and the Enterprise: A Model-Based Analysis of Single Sign-On Authentication. Enterprise Distributed Object Computing Conference (EDOC), 2011 15th IEEE International. Anais...: ENTERPRISE DISTRIBUTED OBJECT COMPUTING CONFERENCE (EDOC), 2011 15TH IEEE
INTERNATIONAL. 29 set. 2011.
BERNAL, V. B. 2006. Análise comparativa de “sistemas de autenticação” utilizados em Internetbanking. Disponível em:
<http://www.lsi.usp.br/~volnys/academic/trabalhos-orientados/Analise-comparativade-sistemas-de-autenticacao-utilizados-em-internetbanking.pdf>. Acesso em: 22 abr. 2013.
BUCKER, A. et al. Federated Identity Management And Web Services Security With IBM Tivoli Security Solutions. Vervante, 2005.
CARMODY, S. et al. InCommon technical requirements and information. Vol. 2005.
CHADWICK, D. W. Foundations of Security Analysis and Design V. In: ALDINI, A.; BARTHE, G.; GORRIERI, R. (Eds.). Berlin, Heidelberg: Springer-Verlag, 2009. p. 96–120.
CHAPPEL, D. Introducing Windows CardSpace. Msdn technical articles. Disponível
em: <http://msdn.microsoft.com/en-us/library/aa480189.aspx>. Acesso em: 16 maio. 2013.
CHARAS, M. Security in OpenID. Tese de Mestrado—Suécia: Royal Institute of Technology, 2009.
CHU, D.; LIAO, Q.; ZHAO, J. Open identity management framework for mashup. Anais... In: IEEE 2ND SYMPOSIUM ON WEB SOCIETY (SWS). 2010.
42
FELD, S.; POHLMANN, N. Security analysis of OpenID, followed by a reference implementation of an nPA-based OpenID provider. Gelsenkirchen University of Applied Sciences, 2010. Disponível em:
<https://www.internet-sicherheit.de/fileadmin/images/team/Security-analysis-of-OpenID-ISSE-2010-paper.pdf>. Acesso em: 13 maio. 2013.
GALVÃO, A. S. P. Análise dos aspectos de segurança dos protocolos de
compartilhamento NFS e CIFS. Trabalho de Conclusão de Curso. São Paulo:
Faculdade SENAC de Ciências Exatas e Tecnologia, 2005.
GUIMARÃES, R. S. Análise comparativa de sistemas de autenticação utilizados
em Internet Banking. Trabalho de Conclusão de Curso. São Paulo: Faculdade
SENAC de Ciências Exatas e Tecnologia, 2006.
IONITA, M. G. Secure Single Sign-On using CAS and OpenID. Journal of Mobile, Embedded and Distributed Systems, v. 4, n. 3, p. 159–167, 30 set. 2012.
ISO/IEC 17799:2005. Information technology – Security technical – Code of pratice for information security management.
KUMARAGURU, P. et al. Protecting People from Phishing: The Design and Evaluation of an Embedded Training Email System. Relatório Técnico CMU-CyLab-
06-017, CyLab, Carnegie Mellon University. Novembro, 2006.
LODHA, A; SARMA, R. A Single Sign-On Approach. Avenue A | Razorfish Slant. Mar.
2006.
MALER, E.; REED, D. The Venn of Identity: Options and Issues in Federated Identity Management. IEEE Security Privacy, v. 6, n. 2, p. 16–23, 2008.
MSDN LIBRARY. Microsoft Kerberos (Windows). Especificação. Disponível em:
<http://msdn.microsoft.com/en-us/library/aa378747(VS.85).aspx>. Acesso em: 14 jun. 2013.
NEUMAN, B. C.; TS’O, T. Kerberos: An Authentication Service for Computer Networks: USC/ISI. IEEE Communications, Sep 94. Disponível em:
<http://gost.isi.edu/publications/kerberos-neuman-tso.html>. Acesso em: 14 jun. 2013.
OH, H.-K.; JIN, S.-H. The Security Limitations of SSO in OpenID. 10th International Conference on Advanced Communication Technology, 2008. ICACT 2008. Anais...:
43
10TH INTERNATIONAL CONFERENCE ON ADVANCED COMMUNICATION TECHNOLOGY (ICACT), 2008.
OpenID FOUNDATION. OpenID Authentication 1.1. Disponível em:
<http://OpenID.net/specs/OpenID-authentication-1_1.html>. 2006. Acesso em: 22 abr. 2013.
PEIXOTO, M. Uma análise geral sobre Single Sign On. Webinsider. 9 Jan 2012.
RECORDON, D.; REED, D. OpenID 2.0. ACM Press, 2006. Disponível em:
<http://portal.acm.org/citation.cfm?doid=1179529.1179532>. Acesso em: 21 abr.
2013
ROGAWAY, P. Nonce-based symmetric encryption. Anais...: Fast Software Encryption, 2004. Disponível em: <http://link.springer.com/chapter/10.1007/978-3-540-25937-4_22>. Acesso em: 17 maio. 2013
SABINO, A. 2005. Análise dos aspectos de segurança dos protocolos de compartilhamento NFS e CIFS. Disponível em:
<http://www.lsi.usp.br/~volnys/academic/trabalhos-orientados/Analise-dos-aspectosde-seguranca-dos-protocolos-de-compartilhamento-NFS-e-CIFS.pdf>.
Acesso em: 22 abr. 2013.
SHIBBOLETH CONSORTIUM. What’s Shibboleth?. Disponível em:
<http://shibboleth.net/about/index.html>. Acesso em: 10 maio. 2013.
SOVIS, P.; KOHLAR, F.; SCHWENK, J. Security Analysis of OpenID. Anais...:
Information Security Solutions Europe (ISSE’10) Conference. Disponível em: <http://subs.emis.de/LNI/Proceedings/Proceedings170/329.pdf>. Acesso em: 13 maio. 2013
SUN, S.-T. et al. OpenID-enabled browser: towards usable and secure web single sign-on. CHI ’11 Extended Abstracts on Human Factors in Computing Systems. Anais...: CHI EA ’11.New York, NY, USA: ACM, 2011. Disponível em:
<http://doi.acm.org/10.1145/1979742.1979763>. Acesso em: 13 mar. 2013;
WANG, H. et al. A New Secure OpenID Authentication Mechanism Using OneTime Password (OTP). 2011 7th International Conference on Wireless
Communications, Networking and Mobile Computing (WiCOM). Anais... In: 2011 7TH
INTERNATIONAL CONFERENCE ON WIRELESS COMMUNICATIONS,
NETWORKING AND MOBILE COMPUTING (WICOM). Set 2011.
44
WANG, R.; CHEN, S.; WANG, X. Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services. 2012 IEEE Symposium on Security and Privacy (SP). Anais...: 2012 IEEE SYMPOSIUM ON SECURITY AND PRIVACY (SP). 2012
WANGHAM, M. S. et al. Gerenciamento de identidades federadas. Minicurso SBSeg 2010 Fortaleza-CE, 2010.
WATANABE, R.; TANAKA, T. Federated Authentication Mechanism using Cellular Phone - Collaboration with OpenID. Anais... In: SIXTH INTERNATIONAL
CONFERENCE ON INFORMATION TECHNOLOGY: NEW GENERATIONS, 2009. ITNG ’09. 2009.
YAHOO!. Selo de autenticidade personalizado do Yahoo! Disponível em: <https://protect.login.yahoo.com>. Acesso em: 3 jun. 2013.
YOU, X. e ZHU, Y. Research and Design of Web Single Sign-On Scheme. 2012
IEEE Symposium on Robotics and Applications (ISRA). Anais... In: 2012 IEEE
SYMPOSIUM ON ROBOTICS AND APPLICATIONS (ISRA). Jun 2012.
ZHAO, G.; ZHENG, D.; CHEN, K. Design of single sign-on. IEEE International
Conference on E-Commerce Technology for Dynamic E-Business, 2004. Anais... In:
IEEE INTERNATIONAL CONFERENCE ON E-COMMERCE TECHNOLOGY FOR
DYNAMIC E-BUSINESS, 2004
