implantação de um ambiente de autenticação centralizado para

FLÁVIO LOPES DE MORAIS
IMPLANTAÇÃO DE UM AMBIENTE DE
AUTENTICAÇÃO CENTRALIZADO PARA
APLICAÇÕES WEB
LAVRAS-MG
2013
FLÁVIO LOPES DE MORAIS
IMPLANTAÇÃO DE UM AMBIENTE DE AUTENTICAÇÃO
CENTRALIZADO PARA APLICAÇÕES WEB
Monografia
de
graduação
apresentada
ao
Colegiado do Curso de Sistemas de Informação da
Universidade Federal de Lavras, para a obtenção do
título de Bacharel em Sistemas de Informação.
Orientador
Dr. Joaquim Quinteiro Uchôa
LAVRAS-MG
2013
Dedico esta, bem como todas as minhas demais conquistas, aos meus pais José
Osmar e Maria Helena, minhas irmãs Valéria e Mirene, meu sobrinho e afilhado
Davi e em especial a minha querida esposa Claudiane.
AGRADECIMENTOS
A Deus pelo dom da vida e por me guiar durante esta caminhada.
À minha esposa Claudiane, pessoa com quem amo partilhar a vida,
obrigado pelo carinho, a paciência e por sua capacidade de me trazer
paz na correria de cada semestre. E não deixando de agradecer de
forma grandiosa meus pais, José Osmar e Maria Helena, e minhas
irmãs, Valéria e Mirene, que com muito carinho e apoio, não mediram
esforços para que eu chegasse até esta etapa de minha vida.
À Universidade Federal de Lavras (UFLA) e ao Departamento de Ciência da Computação (DCC) pela oportunidade da formação superior.
À Diretoria de Gestão de Tecnologia da Informação (DGTI) e seus colaboradores por possibilitar a realização deste trabalho. A produção
compartilhada com amigos nesses espaços foi a melhor experiência
da minha formação acadêmica e aperfeiçoamento profissional.
Ao professor Dr. Joaquim Quinteiro Uchôa, pela orientação, paciência e conselhos que foram de grande valia para a realização deste
trabalho.
Aos membros da banca examinadora Hermes Pimenta de Moraes Júnior e Eder Teixeira de Andrade, por aceitarem o convite para composição da mesma.
Enfim, a todos que, de algum modo, participaram de mais um capítulo
de minha história, os meus sinceros agradecimentos.
"Nós somos aquilo que fazemos repetidamente.
Excelência, então, não é um modo de agir,
mas um hábito."
(Aristóteles)
RESUMO
Após analisar os sistemas web em operação no âmbito da Universidade Federal de
Lavras (UFLA) e sob gerência da Diretoria de Gestão de Tecnologia da Informação (DGTI) desta universidade, identificou-se a necessidade de minimizar fatores
que comprometiam a segurança do processo de autenticação de usuários dessas
aplicações. Foi levantado que a DGTI possui como prática a utilização de credenciais únicas para autenticar usuários em seus diversos sistemas web, sendo estas
credenciais informadas diretamente nas aplicações. Como foi abordado durante o
desenvolvimento do presente trabalho, por razões de segurança, a manipulação de
credenciais únicas feita diretamente nas aplicações deve ser evitada. No intuito de
resolver o problema levantado, foi proposta a implantação de uma ferramenta de
autenticação centralizada no ambiente em que estes sistemas estão inseridos. Após
a avaliação de três soluções de autenticação web Single Sign-On (SSO), a que melhor atendeu aos requisitos exigidos pelo ambiente foi o Central Authentication
Service (CAS). Após a implantação do CAS e integração de diversos sistemas sob
responsabilidade da DGTI, foi obtido como resultado uma melhora no que se refere a utilização segura de credenciais únicas em um ambiente web.
Palavras-Chave: Autenticação Centralizada. Central Authentication Service. DGTI.
Single Sign-On. UFLA.
LISTA DE FIGURAS
2.1
Modelo de autenticação tradicional . . . . . . . . . . . . . . . . . . .
5
2.2
Modelo descentralizado de autenticação com credencial única . . . .
6
2.3
Modelo centralizado de autenticação . . . . . . . . . . . . . . . . . .
8
2.4
Troca de pacotes entre o cliente, o KDC e o servidor de aplicação . .
12
2.5
Autenticação descentralizada . . . . . . . . . . . . . . . . . . . . . .
13
2.6
Autenticação com identidade federada . . . . . . . . . . . . . . . . .
14
2.7
Utilização de bibliotecas cliente para autenticação via CAS . . . . . .
19
2.8
Sequência de passos para autenticação via CAS . . . . . . . . . . . .
21
2.9
Autenticação federada com o Shibboleth . . . . . . . . . . . . . . . .
24
2.10 IdP utilizando o CAS para autenticação . . . . . . . . . . . . . . . .
25
3.1
Autenticação única através de fontes distintas. . . . . . . . . . . . . .
27
3.2
Replicação para o LDAP de alterações na base de dados controlada
pelo SIG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3
Proporção de sistemas utilizando SSL . . . . . . . . . . . . . . . . .
28
3.4
Utilização de credencial única por sistemas não gerenciados pela DGTI 29
4.1
Configuração do módulo LDAP no CAS . . . . . . . . . . . . . . . .
37
4.2
Parâmetros de conexão do CAS ao LDAP . . . . . . . . . . . . . . .
37
4.3
Adicionando o LDAP como fonte de autenticação no CAS . . . . . .
38
4.4
Aplicação PHP utilizando a biblioteca phpCAS . . . . . . . . . . . .
39
5.1
Percentual de sistemas integrados ao CAS após implantação . . . . .
42
5.2
Solução alcançada com o projeto . . . . . . . . . . . . . . . . . . . .
43
SUMÁRIO
1
INTRODUÇÃO
1
1.1
Contextualização e Motivação . . . . . . . . . . . . . . . . . . . . .
1
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2
REFERENCIAL TEÓRICO
2.1
4
Modelos de autenticação . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Modelo descentralizado de autenticação (modelo tradicional) . . . .
4
2.1.2
Modelo descentralizado de autenticação com credencial única . . .
6
2.1.3
Modelo centralizado de autenticação com entrada única . . . . . . .
7
2.2
Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Federação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4
Escopos de soluções Single Sign-On (SSO) . . . . . . . . . . . . . .
14
2.4.1
SSO de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.2
Web SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.3
Web SSO federado . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5
Single Logout (SLO) . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.6
Ferramentas web SSO . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.6.1
Java Open Single Sign-On Community Edition . . . . . . . . . . .
17
2.6.2
Central Authentication Service (CAS) . . . . . . . . . . . . . . . .
18
2.6.3
3
Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
DESCRIÇÃO DO AMBIENTE E APRESENTAÇÃO DO PROBLEMA 26
3.1
Descrição do ambiente . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2
Apresentação do problema . . . . . . . . . . . . . . . . . . . . . . .
27
3.3
Possibilidades de solução . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.1
Utilização de SSL em todos os sistemas . . . . . . . . . . . . . . .
29
3.3.2
Autenticação centralizada . . . . . . . . . . . . . . . . . . . . . .
30
3.4
Solução ideal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.5
Solução adotada . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.6
Ferramenta web SSO escolhida . . . . . . . . . . . . . . . . . . . . .
33
4
METODOLOGIA E DESENVOLVIMENTO
4.1
35
Instalação e configuração do CAS . . . . . . . . . . . . . . . . . . .
36
4.1.1
Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.1.2
Configuração do modo de autenticação . . . . . . . . . . . . . . .
36
Integração dos sistemas ao CAS . . . . . . . . . . . . . . . . . . . .
38
4.2.1
Sistemas desenvolvidos pela DGTI . . . . . . . . . . . . . . . . . .
38
4.2.2
Sistemas de terceiros . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2
5
RESULTADOS E DISCUSSÃO
42
6
CONCLUSÃO
45
7
GLOSSÁRIO
50
1
1 INTRODUÇÃO
Neste capítulo, é feita uma contextualização do tema tratado, são descritos os objetivos deste trabalho e a sua estruturação.
1.1
Contextualização e Motivação
Manter a segurança em ambientes com modelo tradicional de autenticação, em que
cada sistema possui o controle sobre a própria forma de autenticação de usuários,
costuma ser uma atividade mais trabalhosa devido ao esforço em manter as bases
de dados atualizadas e/ou sincronizadas. Este modelo tradicional, de certa forma,
contribui para o aumento na quantidade de incidentes de segurança por diversos
fatores tais como: o armazenamento de senhas para consulta posterior, o desencorajamento da troca contínua dessas senhas e outros fatores citados mais adiante
neste trabalho. A substituição deste modelo tradicional por outro que viabilize uma
autenticação centralizada e segura, englobando os mais diversos sistemas existentes em um ambiente é uma alternativa que deve ser considerada. Esta estrutura de
autenticação centralizada pode ser alcançada com a utilização de soluções de autenticação Single Sign-On (SSO). Um sistema SSO possibilita ao usuário o acesso
a vários serviços, autenticando-se apenas uma vez através de uma central de autenticação.
A Diretoria de Gestão de Tecnologia da Informação (DGTI)1 , órgão suplementar vinculado à Superintendência de Planejamento da Pró-Reitoria de Planejamento e Gestão da Universidade Federal de Lavras (UFLA)2 é responsável por
desenvolver as atividades de gestão da tecnologia da informação no âmbito da uni1 http://www.dgti.ufla.br/
2 http://www.ufla.br/
2
versidade. Esta diretoria possui como prática a utilização de credenciais3 únicas
para a maioria dos sistemas web por ela desenvolvidos e/ou controlados, sendo
essas credenciais informadas diretamente nas aplicações. De acordo com AUBRY,
MATHIEU e MARCHAL (2004), a prática de permitir o informe de credenciais
únicas diretamente nas aplicações deve ser evitado, pois o comprometimento de
qualquer sistema pode colocar todo o ambiente em risco. Foi proposto no presente trabalho, efetuar um levantamento do modelo de autenticação utilizado pelas
aplicações web mantidas pela DGTI, avaliar possíveis soluções e ferramentas de
autenticação web SSO e fazer a implantação daquela que melhor atendesse aos
requisitos do ambiente. E desta forma, contribuir para o aumento da segurança na
autenticação dos sistemas computacionais existentes no âmbito da Universidade
Federal de Lavras.
1.2
Objetivos
O presente trabalho teve por objetivo geral aumentar a segurança na autenticação
de usuários dos sistemas web mantidos pela DGTI, através da implantação de uma
ferramenta de autenticação web SSO nesse ambiente. Os objetivos específicos
foram:
1) Realização de uma revisão bibliográfica sobre ferramentas web SSO, modelos e escopos de autenticação;
2) Levantamento da estrutura e segurança na autenticação de aplicações web
mantidas pela DGTI;
3O
termo credencial pode ser definido como algo que possibilita ao usuário o acesso a algum
recurso. Neste trabalho refere-se ao conjunto usuário/senha informados para autenticação nos sistemas.
3
3) Avaliação de soluções web SSO afim de encontrar aquela que melhor atendesse às necessidades do ambiente analisado;
4) Implantação da ferramenta web SSO selecionada;
5) Efetuação das alterações necessárias para integração do grupo de sistemas
da DGTI à ferramenta web SSO implantada.
1.3
Estrutura do Trabalho
Este trabalho está organizado da seguinte forma:
Capítulo 2 (Referencial teórico): são abordados os principais conceitos teóricos relacionados aos assuntos contemplados nesta pesquisa.
Capítulo 3 (Descrição do ambiente e apresentação do problema): levantamento da estrutura existente de autenticação de usuários em sistemas web operantes no âmbito da UFLA e discussões sobre o problema e soluções.
Capítulo 4 (Metodologia e Desenvolvimento): é apresentada a metodologia
de pesquisa adotada no trabalho e o seu desenvolvimento.
Capítulo 5 (Resultados e discussão): apresentação dos resultados alcançados
com a execução deste trabalho.
Capítulo 6 (Conclusão): apresentação das conclusões, considerações e sugestão de trabalhos futuros.
4
2 REFERENCIAL TEÓRICO
Esta seção apresenta uma revisão bibliográfica para dar respaldo científico no desenvolvimento deste trabalho.
2.1
Modelos de autenticação
Com o aumento na quantidade de sistemas informatizados nas organizações, tornase também necessário o aumento de investimentos em soluções de segurança. Para
se proteger contra ataques externos à rede, uma boa implementação de alguma solução de firewall é geralmente suficiente, mas para a rede interna a questão torna-se
mais complexa. Ao contrário do que se possa imaginar, a grande maioria dos incidentes de segurança são de origem interna, provocados por indivíduos que fazem
parte da própria instituição (MIT, 2012). Um fator que pode contribuir para o
aumento no quadro de insegurança interno em uma organização, é o modelo de
autenticação adotado por seus sistemas. Neste trabalho, modelo de autenticação é
tratado como a forma em que um conjunto de sistemas pertencentes ao mesmo ambiente manipulam as credenciais dos usuários. A seguir, são listados os principais
modelos de autenticação relevantes para o desenvolvimento desta pesquisa.
2.1.1
Modelo descentralizado de autenticação (modelo tradicional)
Modelo descentralizado de autenticação (ou modelo tradicional de autenticação),
pode ser definido como aquele geralmente criado pelo aumento não planejado de
sistemas informatizados em qualquer organização. Neste modelo cada sistema
gerencia a sua própria base de usuários, gerando uma estrutura descentralizada de
autenticação e gerência de credenciais.
5
Ilustrado pela Figura 2.1, este modelo permite que uma mesma pessoa possua
credenciais diferentes para cada um dos sistemas que tenha acesso. Este modelo
incentiva o armazenamento (sobre a mesa, em mídias digitais, e-mail etc.) de
credenciais para consulta posterior, contribuindo para o aumento nos riscos com
incidentes de segurança (HURSTI, 1997). Pode-se destacar também, que o modelo
tradicional pode desencorajar a troca contínua das senhas por parte do usuário nas
diversas aplicações em que possua permissão de acesso.
Figura 2.1: Modelo de autenticação tradicional
Fonte: Adaptado de (SWITCHAAI, 2013)
Dependendo da quantidade de sistemas, do nível de dificuldade para definição
das senhas e da periodicidade de exigência na renovação dessas, o esquecimento de
senhas pode gerar uma demanda diária para os setores de suporte da organização
(VOLCHKOV, 2001). Neste sentido, fica claro que tal situação contribui para a
elevação de custos, diminuição da produtividade e aumento da insatisfação dos
envolvidos.
Este modelo, segundo HURSTI (1997), torna complicada a administração de
usuários principalmente quando algum usuário é desligado da instituição. Geralmente não se tem controle sobre quais sistemas a pessoa possui acesso, sendo geralmente necessário verificar em todos. Neste caso a segurança pode ser compro-
6
metida caso a pessoa permaneça com permissão indevida de acesso em qualquer
dos sistemas.
2.1.2
Modelo descentralizado de autenticação com credencial única
Frente aos problemas decorrentes do modelo de autenticação tradicional, muitas
organizações procuram evoluir para um modelo que possibilite a uma pessoa utilizar a mesma credencial para acesso a todas as aplicações (SWITCHAAI, 2013),
modelo ilustrado pela Figura 2.2. Neste modelo é mantida uma base centralizada
de usuários e todas as aplicações se autenticam na mesma fonte. Desta forma o
problema com múltiplas senhas é eliminado, facilitando a gerência de usuários.
Esta base centralizada pode ser um banco de dados convencional, um diretório
Lightweight Directory Access Protocol (LDAP), dentre outros.
Figura 2.2: Modelo descentralizado de autenticação com credencial única
Fonte: Adaptado de (SWITCHAAI, 2013)
Neste modelo, cada aplicação manipula diretamente as credenciais dos usuários, mantendo a sua própria página de login. Se não muito bem controlado, este
7
modelo torna-se bastante vulnerável a ocorrência de incidentes de segurança. Isso
se deve a dois fatores principais:
1. Se ao menos uma aplicação for comprometida, o invasor poderá ter acesso
às credenciais de qualquer usuário que se autenticar neste sistema. Com as
credenciais em mãos, devido a unicidade, poderá se autenticar em qualquer
outra aplicação em que aquele usuário tenha acesso. Uma forma simples de
comprometer o sistema é através da alteração da sua página de autenticação.
Como cada sistema recebe a senha do usuário em texto plano, a mesma pode
ser manipulada e enviada com facilidade para qualquer lugar.
2. Dependendo do nível de controle sobre o desenvolvimento e implantação de
novos sistemas e servidores no ambiente, a garantia da segurança na manipulação de credenciais em cada aplicação pode ser insuficiente. É necessário
garantir que cada sistema faça a manipulação segura das credencias recebidas. Esta tarefa pode não ser trivial a partir do momento em que utiliza-se
sistemas desenvolvidos sob coordenação externa à empresa. É necessário
garantir também que cada aplicação funcione sobre conexão segura, caso
contrário, as credenciais poderão ser facilmente captadas, já que trafegam
em texto plano pela rede.
Desta forma, segundo AUBRY, MATHIEU e MARCHAL (2004), é desejável
que as credenciais dos usuários não sejam informadas diretamente nas aplicações.
2.1.3
Modelo centralizado de autenticação com entrada única
Como alternativa aos modelos descentralizados de autenticação, uma solução Single Sign-On (SSO) pode ser adotada. Segundo HURSTI (1997) um ambiente com
autenticação SSO torna possível, de forma segura, que os usuários utilizem apenas
uma credencial para acesso a todos os serviços em que possuam permissão. Ainda
8
de acordo com HURSTI (1997), esse tipo de ambiente possibilita que o usuário se
autentique apenas no primeiro acesso, eliminando a necessidade de autenticação
adicional para acesso aos demais serviços disponibilizados no ambiente. A Figura
2.3 ilustra o funcionamento deste modelo, o módulo de autenticação não fica mais
nas aplicações, e sim na central de autenticação.
Figura 2.3: Modelo centralizado de autenticação
Fonte: Adaptado de (SWITCHAAI, 2013)
Neste modelo existe a figura de um servidor de autenticação, responsável por
fornecer a página de login para todos os sistemas. As credenciais não são mais
informadas diretamente nas aplicações, mas sim na central de autenticação através de um túnel criptografado (AUBRY; MATHIEU; MARCHAL, 2004). Para
garantir a segurança, toda a comunicação entre as aplicações e o servidor de autenticação ocorre também através de um túnel criptografado. Além do aumento
da segurança ao reduzir a exposição da senha dos usuários a vários sistemas, um
ambiente com autenticação SSO proporciona os seguintes benefícios:
Maior facilidade de administração: o controle de usuários torna-se centralizado.
Quando uma pessoa deixa a organização é necessário fazer o bloqueio em
apenas um local.
9
Maior comodidade aos usuários: sendo necessário autenticar-se apenas no primeiro acesso, além da redução na quantidade de senhas a serem lembradas.
Aumento da produtividade no desenvolvimento: pois não é mais preciso desenvolver uma tela de entrada e um controle de autenticação para cada sistema.
Mas é preciso tomar certos cuidados em um ambiente com estrutura de autenticação SSO. Como desvantagens, pode-se listar:
Único ponto de falha: devido ao modelo centralizado de autenticação, se o servidor SSO ficar inoperante ninguém conseguirá autenticar-se em nenhum dos
sistemas que o utilizam para autenticação.
Único ponto de ataque: segundo SARS (1998) uma central de autenticação pode
facilmente tornar-se um atrativo para ataques. Se o servidor SSO puder ser
comprometido, será possível comprometer todos os sistemas que o utilizam
para autenticação de seus usuários.
Ambos os pontos de desvantagem podem ser contornados com uma política
de segurança bem definida. É necessário investir em um ou mais servidores extra
de autenticação, para que tenham a capacidade de assumir o controle em caso de
falhas do servidor de autenticação principal. Torna-se importante também a atualização constante do sistema SSO adotado. Novas versões, além de incorporar novas
funcionalidades, geralmente trazem diversas correções de falhas de segurança.
10
2.2
Kerberos
O Kerberos é um protocolo open source para autenticação SSO em rede, criado
na década de 80 pelo Massachusetts Institute of Technology (MIT)1 como parte
do projeto Athena (MIT, 2013). Em 1993 o Kerberos tornou-se um padrão Internet Engineering Task Force (IETF)2 passando a ser largamente utilizado, sendo
atualmente um protocolo referência quando o assunto é autenticação SSO (MIT,
2013). O Kerberos está presente na maioria dos sistemas operacionais de diversas
companhias, como a Microsoft3 , Apple4 , RedHat5 e Oracle6 . De acordo com MIT
(2013), o Kerberos utiliza o conceito de tickets na implementação da funcionalidade de SSO. Um ticket é algo que o cliente apresenta ao servidor de aplicação para
provar a autenticidade da sua identidade sem a necessidade de nova autenticação.
O processo de autenticação e autorização do Kerberos, embora seja concentrado em um único servidor físico, segundo MIT (2013) pode ser logicamente dividido em três partes, que conjuntamente são chamadas de Key Distribution Center
(KDC):
1. Database (banco de dados): armazena informações sobre associações de
usuários aos serviços, tickets e suas definições de validade, senhas e suas
definições de validade, dentre outras informações importantes;
2. Authentication Server (AS): O AS é o serviço de autenticação inicial onde
o usuário ainda não autenticado informa suas credenciais para autenticação.
Após o usuário autenticar-se o AS fornece ao mesmo um Ticket Granting
1 http://web.mit.edu/
2 http://www.ietf.org/
3 http://www.microsoft.com/
4 http://www.apple.com/
5 http://www.redhat.com/
6 http://www.oracle.com/us/sun
11
Ticket (TGT). O TGT é o ticket utilizado pelo usuário para conseguir acesso
aos serviços sem necessidade de nova autenticação;
3. Ticket Granting Server (TGS): É o componente que faz a distribuição de service ticket (ST) para clientes com TGTs válidos. Os STs são tickets apresentados pelo cliente ao servidor de aplicação para conseguir acesso ao serviço
desejado.
Ainda segundo MIT (2013), a troca de pacotes entre o cliente e o KDC e entre
o cliente e o servidor de aplicação pode ser resumida da seguinte forma, melhor
visualizado pela Figura 2.4:
• AS_REQ: Requisição inicial de autenticação feita pelo usuário ao AS;
• AS_REP: Resposta enviada pelo AS à requisição anterior. O pacote recebido
inclui o TGT (criptografado com uma chave secreta do TGS) e a chave de
sessão (criptografada com a chave secreta do usuário);
• TGS_REQ: Requisição do usuário ao TGS solicitando um ST. O pacote
enviado inclui o TGT obtido no passo anterior e um autenticador gerado
pelo cliente e criptografado com a chave de sessão obtida;
• TGS_REP: Resposta enviada pelo TGS à requisição anterior. O pacote recebido inclui o ST (criptografado com a chave secreta do serviço) requisitado
e também uma chave de sessão do serviço, criptografada utilizando a chave
de sessão gerada pelo AS;
• AP_REQ: Requisição enviada pelo cliente ao servidor de aplicação solicitando acesso ao serviço. O pacote inclui o ST obtido na resposta anterior
e um autenticador gerado pelo cliente e criptografado com a utilização da
chave de sessão de serviço gerada pelo TGS no passo anterior;
12
• AP_REP: Resposta enviada pelo servidor de aplicação ao cliente para provar
que o servidor é realmente aquele esperado pelo cliente. Esta etapa não é
obrigatória, isto somente ocorre quando existe a necessidade de autenticação
mútua entre cliente e servidor de aplicação.
Figura 2.4: Troca de pacotes entre o cliente, o KDC e o servidor de aplicação
Fonte: Adaptado de (MIT, 2013)
2.3
Federação
No âmbito de autenticação SSO, uma federação é um tipo de rede de confiança que
possibilita às instituições participantes, denominadas unidades federadas, a utilização de métodos distintos de autenticação local, mantendo a interoperabilidade
entre elas (SWITCHAAI, 2013). As informações sobre as pessoas vinculadas às
instituições continuam sendo mantidas localmente, e cada instituição participante
estabelece seu próprio modelo de gestão de identidade. Ou seja, cada instituição
mantém o controle sobre como são mantidas informações de usuários e qual mé-
13
todo de autenticação local será utilizado, essa propriedade é chamada de identidade
federada. As Figuras 2.5 e 2.6 ilustram um ambiente onde uma mesma pessoa possui vínculos com mais de uma instituição. No modelo tradicional, ilustrado pela
Figura 2.5, o usuário precisa de uma credencial para cada um dos sistemas espalhados pelas instituições. Já no modelo com identidade federada, ilustrado pela
Figura 2.6, o usuário somente precisa das credenciais cedidas em sua instituição
de origem.
Figura 2.5: Autenticação descentralizada
Fonte: Adaptado de (SWITCHAAI, 2013)
14
Figura 2.6: Autenticação com identidade federada
Fonte: Adaptado de (SWITCHAAI, 2013)
2.4
Escopos de soluções Single Sign-On (SSO)
O escopo de uma solução de autenticação SSO está relacionado ao seu ambiente
de atuação. Neste trabalho são conceituados três diferentes escopos apresentados
a seguir.
2.4.1
SSO de rede
Exemplificado neste trabalho pelo Kerberos, é a forma de autenticação e autorização mais amplamente utilizada atualmente (MIT, 2013). O Kerberos atua nos
controles de autenticação e autorização SSO do usuário aos recursos de rede. O
seu funcionamento é desenvolvido para possibilitar que determinado usuário efetue logon em seu terminal, e, de forma transparente, consiga acesso a todos os
recursos de rede que possua permissão (BUTLER et al., 2006).
15
2.4.2
Web SSO
Com o aumento na quantidade de sistemas web houve a necessidade de criar soluções SSO para este ambiente, surgindo o conceito de web SSO. Um web SSO
consiste em uma solução que possibilita o controle centralizado da autenticação de
sistemas web, através de um servidor de autenticação (HITACHI, 2013). Quando
um usuário tenta acesso a determinado recurso, o mesmo é redirecionado para
autenticar-se no servidor de autenticação. Caso o usuário já tenha se autenticado
anteriormente para acessar outro sistema, o acesso às demais aplicações é feito
diretamente, sem necessidade de nova autenticação por parte do usuário. Após a
primeira autenticação, todo o processo é feito de forma transparente pelo agente
que controla o ambiente web SSO (HITACHI, 2013).
2.4.3
Web SSO federado
O conceito de federação surge da necessidade de interoperabilidade, em nível de
autenticação, de diferentes organizações chamadas unidades federadas. Tal conceito possibilita que um usuário pertencente a uma instituição consiga autenticar-se
em outra, com as credenciais da sua instituição de origem (SWITCHAAI, 2013).
Este modelo de tecnologia pode ser considerado uma generalização do conceito de
web SSO, já que possibilita criar um ambiente SSO global (no âmbito da federação) a partir de soluções SSO utilizadas localmente em cada unidade federada.
Como exemplo da aplicação deste conceito no Brasil, existe a Comunidade
Acadêmica Federada (CAFe)7 . A CAFe é uma federação que envolve diversas
instituições de ensino e pesquisa brasileiras. Entre as instituições participantes é
formada uma rede de confiança que possibilita aos usuários o acesso a recursos de
outras instituições, utilizando credenciais cedidas em sua instituição de origem. A
7 http://www.rnp.br/servicos/cafe.html
16
federação CAFe utiliza a plataforma Shibboleth8 para implementar o conceito de
identidade federada entre as instituições participantes.
2.5
Single Logout (SLO)
Enquanto um SSO permite ao usuário autenticar-se uma única vez para acessar diversos sistemas, o Single Logout (SLO), conhecido também por Single Sign-Out,
significa que ao efetuar logout de uma das aplicações o usuário perderá acesso a todas as outras em que esteja conectado (LAB; FEDERATIONS, 2013). Nem todos
os sistemas web SSO oferecem suporte a esta funcionalidade. Embora pareça simples, a funcionalidade de SLO pode ser de difícil alcance, pois envolve a exclusão
da seção do usuário diretamente no servidor de aplicação de cada um dos sistemas em que o usuário esteja conectado. Como mencionado por Lab e Federations
(2013) uma das grandes questões envolvendo a utilização de SLO, é que o mesmo
pode trazer falsa sensação de segurança ao passar a impressão errada ao usuário de
que o mesmo foi desconectado de todas as aplicações ao efetuar o logout em uma
delas. Dependendo da situação, mesmo com o SLO configurado, alguma aplicação pode não ser desconectada por falha no recebimento da requisição de logout
enviada pelo servidor web SSO.
Os sistemas web SSO que oferecem suporte a SLO implementam geralmente
esta função em forma de uma funcionalidade configurável, tornando possível configurar todo o ambiente, somente parte dele ou mesmo desabilitar a funcionalidade.
8 http://shibboleth.net/
17
2.6
Ferramentas web SSO
Nesta seção é feito um levantamento de algumas soluções web SSO disponibilizadas gratuitamente na Internet. São destacadas as características principais de cada
uma delas. Nas ferramentas consideradas mais relevantes para contribuição neste
trabalho foram apresentados também alguns detalhes sobre o seu funcionamento.
2.6.1
Java Open Single Sign-On Community Edition
Java Open Single Sign-On Community Edition (JOSSO CE) consiste em uma solução SSO segura para aplicações ou serviços web. JOSSO CE é desenvolvido
em Java EE9 com a utilização do Spring Framework10 e distribuído sobre licença
GPL11 , sendo um software livre e de código aberto (JOSSO, 2013). Possui como
características principais:
• Suporte a Security Assertion Markup Language (SAML) 12 ;
• Suporte a LDAP e base de dados para armazenamento de informações e
credenciais;
• Suporte a integração com o Spring Framework, aplicações desenvolvidas
em PHP13 , ASP14 , Perl15 , Python16 dentre outras;
9 http://www.oracle.com/technetwork/java/javaee/
10 http://projects.spring.io/spring-framework/
11 http://www.gnu.org/copyleft/gpl.html
12 https://www.oasis-open.org/committees/security/
13 http://php.net/
14 http://www.asp.net/
15 http://www.perl.org/
16 http://www.python.org/
18
• Pode ser instalado em diferentes servidores de aplicação, tais como: Apache
Tomcat17 , JBoss18 , Microsoft Windows IIS19 , dentre outros.
2.6.2
Central Authentication Service (CAS)
O CAS20 é um sistema de autenticação web SSO concebido em 2001 pela universidade de Yale21 , se tornando um projeto mantido pelo consórcio Jasig22 a partir
de 2005 (JASIG, 2013). O CAS é desenvolvido com linguagem de programação Java23 , e disponibiliza várias bibliotecas cliente para integração com outras
linguagens (PHP, Java, .NET, Python, Perl, dentre outras). O CAS Possui como
características principais:
• Código aberto e gratuito;
• Suporte a SAML;
• Suporte a LDAP e base de dados para armazenamento de informações e
credenciais;
• Suporte a múltiplas fontes simultâneas de autenticação;
• Suporte a integração com Spring Framework e aplicações desenvolvidas em
PHP, ASP, Perl, Python, Java dentre outras;
• Instalação e configuração simplificadas.
O funcionamento da autenticação única com o CAS baseia-se na existência
de um servidor, chamado CAS server, e dos sistemas que o utilizam, através de
17 http://tomcat.apache.org/
18 http://www.jboss.org/
19 http://www.iis.net/
20 http://www.jasig.org/cas/
21 http://www.yale.edu/
22 http://www.jasig.org/
23 http://www.java.com
19
bibliotecas cliente, para autenticação de seus usuários. Como mostra a Figura
2.7, o funcionamento simplificado desta relação entre uma aplicação e biblioteca
cliente segue os seguintes passos:
• A aplicação faz uso de uma biblioteca cliente para redirecionar a autenticação para o CAS server;
• O usuário informa suas credenciais ao CAS server;
• O CAS server então autentica o usuário através de um diretório LDAP ou
qualquer outro modo configurado.
Figura 2.7: Utilização de bibliotecas cliente para autenticação via CAS
Fonte: Adaptado de (JASIG, 2013)
20
O CAS é utilizado como fonte única de autenticação para todas as aplicações
participantes do SSO. Qualquer autenticação é feita diretamente na página de login
do próprio CAS. De acordo com JASIG (2013) a sequência de passos durante
uma autenticação com o CAS pode ser resumida da seguinte forma, ilustrado pela
Figura 2.8:
1. O usuário tenta acesso ao recurso desejado;
2. Caso o usuário já não esteja autenticado, a aplicação em que tentou acesso
o redireciona para o CAS server;
3. O usuário fornece as suas credenciais;
4. O CAS autentica o usuário no diretório LDAP;
5. Após autenticação, o usuário é redirecionado ao recurso inicialmente solicitado;
6. A aplicação pode autorizar, ou não, o acesso do usuário.
O CAS utiliza conceitos semelhantes àqueles utilizados pelo Kerberos. Quando
o usuário autentica-se pela primeira vez na central de autenticação, é concedidolhe um Ticket-granting ticket (TGT). Com a apresentação do TGT ao CAS Server
é liberado o acesso ao serviço pretendido (JASIG, 2013). É importante salientar
que o CAS é utilizado somente para autenticação dos usuários, cabendo ao serviço
cliente autorizar ou não o acesso do usuário autenticado.
Embora não venha configurado em sua instalação padrão, o CAS é munido
de uma funcionalidade que permite o controle sobre quais sistemas podem utilizálo para autenticação (JASIG, 2013). Com esta funcionalidade habilitada, é feito o
cadastro da URL de cada um dos sistemas que utilizam o CAS. Caso algum sistema
não cadastrado tente utilizá-lo como fonte de autenticação, o redirecionamento não
21
Figura 2.8: Sequência de passos para autenticação via CAS
Fonte: Adaptado de (JASIG, 2013)
é feito e uma mensagem informando que aquela aplicação não possui autorização
para utilizar o CAS é exibida.
Segundo JASIG (2013), uma outra funcionalidade que pode ser configurada
no CAS é o renew, que possibilita aos clientes optarem por ficarem fora do SSO,
utilizando o CAS somente como central de autenticação. Essa funcionalidade possibilita ao cliente informar ao CAS server para sempre solicitar que o usuário
autentique-se, mesmo com a existência de uma sessão SSO.
O suporte a SLO é outra funcionalidade que possibilita configuração e traz
flexibilidade. Quando o usuário efetua logout de uma aplicação, ou a sua sessão
expira no CAS server, é disparada a requisição de logout para todos os serviços
em que aquele usuário esteja conectado. O cliente em cada aplicação processa a
requisição de SLO e efetua o logout do usuário, eliminando a sua seção no servidor
22
de aplicação. Segundo JASIG (2013) nem todo cliente suporta a utilização de SLO,
nestes casos pode-se optar em desabilitar essa funcionalidade no ambiente como
um todo.
2.6.3
Shibboleth
O Shibboleth é um projeto open source desenvolvido pela Internet2 Middleware
Initiative24 que possibilita a aplicação do conceito de web SSO federado. O Shibboleth proporciona o gerenciamento de identidade federada para acesso seguro a
recursos de múltiplos domínios, denominados unidades federadas. Ao conjunto
desses domínios colaborativos dá-se o nome federação (MORGAN et al., 2004).
É importante avaliarmos a possibilidade de utilização do Shibboleth como solução web SSO a ser implantada, pois, embora a UFLA não faça parte da federação
CAFe atualmente, é possível que o faça no futuro.
No Shibboleth, cada unidade federada é constituída por um provedor de identidade (Identity Provider) e um provedor de serviço (Service Provider). O Identity Provider (IdP) é o serviço responsável pela autenticação e fornecimento dos
atributos do usuário, enquanto que o Service Provider (SP) é o responsável pela
autorização aos recursos requeridos.
Além dos recursos IdP e SP presentes em cada unidade federada, a arquitetura
Shibboleth contém um serviço chamado Where Are You From (WAYF), responsável por identificar a instituição do usuário. Quando alguém não autenticado tenta
acesso a um recurso disponibilizado na federação, será redirecionado pelo SP para
a página do WAYF. O WAYF apresenta a lista de unidades federadas para que o
usuário escolha a qual pertence. Após a escolha da unidade, o WAYF redireciona o
usuário para o IdP, que requisitará as credenciais do usuário para autenticação. De
24 http://www.internet2.edu/
23
acordo com SWITCHAAI (2013), o funcionamento da autenticação e autorização
no Shibboleth seguem os seguintes passos, ilustrados pela Figura 2.9:
1. O usuário solicita acesso ao recurso desejado;
2. Caso o usuário já não esteja autenticado, o SP redireciona-o para o WAYF;
3. O WAYF apresentara a lista de organizações que fazem parte da federação;
4. Após o usuário selecionar a unidade a qual pertence o WAYF redirecionadoo ao provedor de identidade (IdP) da instituição selecionada. Após o redirecionamento o IdP apresenta o método de autenticação local da instituição;
5. O usuário autentica-se;
6. O SP recebe a garantia de que o usuário foi autenticado pelo IdP;
7. Se necessário, o SP requisita ao IdP atributos adicionais do usuário;
8. O usuário é redirecionado ao recurso solicitado. Com base nos atributos do
usuário o SP pode autorizar, ou não, o acesso ao recurso solicitado.
O Shibboleth é constituído de um conjunto de módulos que, integrados, fornecem um sistema de autenticação SSO federado. A solução completa proposta pelo
Shibboleth está fora do escopo necessário para o presente trabalho, desta forma,
somente seu módulo IdP será verificado. O IdP é o módulo responsável pela autenticação e fornecimento dos atributos do usuário ao SP. Como mencionado em INTERNET2 (2013) o IdP possui um serviço próprio de autenticação web SSO que
pode ser utilizado como meio de autenticação local, ou o IdP pode ser configurado
para utilizar um serviço de autenticação local já operante na própria organização.
De acordo com INTERNET2 (2013), o processo normal feito pelo IdP é:
• Recebe uma solicitação de autenticação no formato SAML a partir do SP;
24
Figura 2.9: Autenticação federada com o Shibboleth
Fonte: Adaptado de (SWITCHAAI, 2013)
• Faz a autenticação do usuário a partir do serviço de autenticação local da
instituição;
• Coleta informações sobre o usuário autenticado na base de dados da organização;
• Aplica políticas de controle sobre quais dados serão disponibilizados ao SP;
• Transmite, de forma segura, as informações coletadas até o SP.
Como mencionado em INTERNET2 (2013), dentre as formas de manipulação de autenticação que podem ser utilizadas pelo IdP está a forma de autenticação
25
definida por External Authn. No mecanismo External Authn o IdP delega a responsabilidade de autenticação do usuário a outro sistema, por exemplo algum sistema
web SSO já operante na organização. Na documentação oficial do Shibboleth são
exibidos exemplos de integração do IdP com o CAS. A Figura 2.10 ilustra uma
configuração do IdP onde é utilizada uma solução externa de autenticação web
SSO, no caso, o CAS. O IdP pode utilizar tanto um banco de dados quanto um
serviço de diretórios para obtenção de atributos extras referente ao usuário autenticado.
Figura 2.10: IdP utilizando o CAS para autenticação
Fonte: Adaptado de (SWITCHAAI, 2013)
26
3 DESCRIÇÃO DO AMBIENTE E APRESENTAÇÃO DO
PROBLEMA
Nesta seção é feito um levantamento de como encontrava-se a estrutura de autenticação de usuários em sistemas web operantes no âmbito da UFLA. Após o
levantamento é feita a apresentação do problema central deste trabalho e discussão
sobre alternativas de solução. Por ultimo são apresentadas a solução adotada e a
ferramenta web SSO escolhida para implantação.
3.1
Descrição do ambiente
A DGTI é um órgão suplementar vinculado à Superintendência de Planejamento
da Pró-Reitoria de Planejamento e Gestão da Universidade Federal de Lavras
(UFLA) e tem por objetivo desenvolver as atividades de gestão da tecnologia da
informação no âmbito da universidade. A DGTI possui como prática, sempre que
possível, a utilização de credencial única para os sistemas por ela desenvolvidos
e/ou mantidos. O identificador único utilizado no ambiente é o mesmo do e-mail
institucional da UFLA. Embora a credencial seja única, a fonte de autenticação
pode variar entre as aplicações, algumas utilizam o diretório LDAP1 outras fazem
a autenticação diretamente no banco de dados. Para exemplificar, a Figura 3.1
ilustra uma situação onde algumas aplicações utilizam o banco de dados para autenticação de seus usuários, e outras utilizam um diretório LDAP. É mantido um
esquema de replicação entre a base de dados de usuários e a base LDAP, esquema
ilustrado pela Figura 3.2. As atualizações efetuadas pelo Sistema Integrado de
Gestão (SIG)2 são refletidas para a base LDAP.
1 http://www.openldap.org/
2 https://www.sig.ufla.br
27
Figura 3.1: Autenticação única através de fontes distintas.
Figura 3.2: Replicação para o LDAP de alterações na base de dados controlada pelo SIG.
3.2
Apresentação do problema
Após levantamento, foram identificados 193 sistemas web desenvolvidos e/ou sob
responsabilidade da DGTI, utilizando credencial única para autenticação. Foi verificado que deste total de sistemas apenas 6 (aproximadamente 32%) funcionavam
sobre conexão segura com a utilização de Secure Sockets Layer (SSL), fato ilustrado pela Figura 3.3.
3
Por razões de segurança, a DGTI não permitiu a divulgação de nomes ou endereços dos sistemas
por ela desenvolvidos.
28
Figura 3.3: Proporção de sistemas utilizando SSL
Como pode ser observado a situação encontrava-se preocupante, visto que
mesmo os sistemas que utilizavam conexão segura estavam em risco. Como já
ressaltado neste trabalho, ambientes onde são utilizadas credenciais únicas para
autenticação devem ser rigorosamente controlados. Em um ambiente com modelo descentralizado de autenticação e que utilize credencial única, se apenas um
dos sistemas não utilizar conexão segura em sua página de autenticação todo o
ambiente estará comprometido.
Outra questão que deve ser evidenciada é relativa ao desenvolvimento de sistemas por setores não subordinados à DGTI. Essas aplicações não possuem nenhum
tipo de controle por parte desta diretoria e em muitos casos, precisam também utilizar as credenciais de e-mail dos usuários para autenticação. Não se sabe ao certo
quantos desses sistemas se utilizam da credencial única dos usuários para autenticação. Não se sabe também quais tipos de cuidados são feitos na manipulação
dessas credenciais, e se funcionam sobre conexão segura ou não. A Figura 3.4
exemplifica esta situação: os sistemas S1, S2 e S3 estão sob gerência da DGTI, já
os sistemas S5 e S6 são controlados por setores externos.
29
Figura 3.4: Utilização de credencial única por sistemas não gerenciados pela DGTI
3.3
Possibilidades de solução
Nesta seção é feita uma análise de possíveis alternativas para solução do problema
apresentado.
3.3.1
Utilização de SSL em todos os sistemas
Uma alternativa clara que amenizaria o problema seria a configuração de todos os
servidores de aplicação para utilização de conexão segura para todos os sistemas.
Neste caso é necessário avaliar a viabilidade em assegurar a utilização de determinadas regras em servidores não gerenciados pela DGTI. A utilização de conexão
segura com SSL garante que a comunicação entre cliente e servidor será criptografada, mas não garante a segurança do sistema como um todo. A utilização de
SSL pode trazer falsa sensação de segurança. Ataques do tipo SQL-Injection, por
30
exemplo, continuam possíveis da mesma forma. O dados transportados entre cliente e servidor são manipulados diretamente pela aplicação, inclusive a senha dos
usuários. Se o invasor comprometer o sistema no servidor de aplicação, de nada
adianta utilizar SSL na conexão com os clientes, pois o mesmo terá livre acesso às
credencias recebidas pela aplicação no momento em que o usuário autenticar-se.
Outra questão a ser analisada é sobre a necessidade de colocar toda a aplicação
ou somente determinadas partes, como a autenticação por exemplo, sobre SSL. Segundo Lee, Jang e Kim (2011) o protocolo SSL utiliza muito mais processamento
e consequentemente consome mais energia. Esta utilização elevada de processamento se deve a fatores como: criptografar e descriptografar, utilizando uma chave
pública, qualquer comunicação entre cliente e servidor. Ainda de acordo com Lee,
Jang e Kim (2011) a utilização elevada de recursos computacionais indica que o
protocolo SSL não é adequado para utilização por dispositivos móveis com pouca
capacidade de processamento e memória. Ou seja, é preciso avaliar quais tipos de
dispositivos acessarão os sistemas, e verificar a viabilidade e real necessidade em
colocar toda a aplicação, ou somente parte dela, sobre o protocolo SSL.
3.3.2
Autenticação centralizada
O ambiente em estudo é caracterizado por uma grande quantidade de sistemas
que fazem uso de credencial única e módulo próprio de autenticação, caracterizando como o modelo descentralizado de autenticação com credencial única, já
apresentado neste trabalho. Quando não muito bem controlado este modelo pode
contribuir para o comprometimento da segurança do ambiente. Como mencionado
por Bhosale (2008) uma solução que facilite o controle sobre a segurança de autenticação em um ambiente com múltiplas aplicações, pode ser alcançado com a
utilização de mecanismos de autenticação SSO.
31
O ambiente de sistemas da DGTI é bastante heterogêneo tanto na diversidade
de padrões de desenvolvimento quanto na variedade de fontes desenvolvedoras.
A utilização de soluções web SSO neste ambiente seria de grande auxílio na prevenção de pontos de falha de segurança. A grande vantagem percebida com a
implantação de uma solução web SSO neste ambiente é devido a remoção da manipulação direta das credenciais pelas aplicações, além de promover a padronização
do processo de autenticação para todo o conjunto de sistemas.
Outra questão a ser verificada é sobre a compatibilidade e viabilidade de adaptação dos sistemas à solução web SSO a ser implantada. É necessário verificar
tanto a facilidade para novos desenvolvimentos quanto ao suporte oferecido por
soluções de terceiros utilizadas no ambiente.
3.4
Solução ideal
Foi verificado que a solução ideal para o ambiente em estudo seria aquela que mitigasse ao máximo as situações em que a segurança do ambiente pudesse ser comprometida por alguma aplicação isolada. Esta preocupação é devido à diversidade
nos padrões de desenvolvimento interno e fontes externas desenvolvedoras não
controladas pela DGTI. A solução que melhor atenderia o ambiente seria aquela
com autenticação centralizada onde as aplicações não tivessem contato direto com
as credenciais dos usuários. Desta forma, foi observado que a solução ideal seria aquela onde todas as aplicações pudessem ser adaptadas e configuradas para
utilizem um sistema web SSO para autenticação de seus usuários.
Durante as pesquisas, foi observado que esta solução idealizada é de difícil
implementação pois, apesar da existência de diversos sistemas web SSO disponíveis no mercado, a grande dificuldade está nas adaptações dos sistemas do ambiente e não na instalação e configuração da aplicação web SSO propriamente dita.
32
Diante disso, alguns dos aspectos que devem ser verificados na escolha da solução
web SSO são a variedade de aplicações, linguagens de programação e frameworks
de desenvolvimento que ofereçam suporte à mesma.
3.5
Solução adotada
Devido a configuração heterogênea do ambiente de sistemas da DGTI, optou-se
pela utilização de uma ferramenta de autenticação web SSO. Além do quesito segurança, os seguintes pontos foram avaliados na escolha da solução de software de
autenticação web SSO:
Gratuita: A ferramenta deve ser de uso livre, sem restrições de qualquer tipo
quanto à sua utilização.
Código aberto: Deve ser de código aberto, possibilitando alterações em sua codificação, caso necessário.
Boa documentação oficial: Necessário possuir uma documentação oficial bem
detalhada.
Exemplos de utilização: Como trata-se de uma solução que faz necessária a sua
integração com outras ferramentas e soluções de terceiros, quanto mais exemplos de utilização e integração, melhor.
Suporte a PHP e Java: Essas são as duas linguagens de programação mais utilizadas pela equipe da DGTI, então é necessário suporte completo às mesmas.
Suporte aos sistemas já utilizados no ambiente: Suporte aos sistemas MediaWiki4 ,
Zimbra Open Source Edition5 , Moodle6 , Jasper Reports Server Community7
4 http://www.mediawiki.org/
5 http://www.zimbra.com/community/
6 http://www.moodle.org.br/
7 http://community.jaspersoft.com/project/jasperreports-server
33
(JasperServer) e Redmine8 . Os sistemas Redmine e Moodle não utilizam
credencial única para autenticação e por isso não serão integrados neste momento, no entanto, faz-se necessário suporte a ambos para possível futura
integração.
3.6
Ferramenta web SSO escolhida
Nesta seção é feita uma análise das soluções web SSO apresentadas no referencial teórico deste trabalho. A escolha da solução teve como base os requisitos do
próprio ambiente, apresentados na seção anterior.
O JOSSO mostrou-se uma boa opção de ferramenta web SSO, sendo uma
solução já consolidada e munida de boa documentação, exemplos de uso e fóruns
ativos de discussão. Porém não foram encontrados casos de sucesso ou exemplos
de configuração para integração do mesmo com os sistemas Jasperserver, Moodle
e MediaWiki. Desta forma, apesar de apresentar diversos pontos favoráveis, a falta
de evidências de suporte aos sistemas mencionados inviabiliza a sua escolha como
solução web SSO a ser implantada.
Já a solução web SSO oferecida pelo módulo IdP do Shibboleth embora ofereça boa documentação explicativa de uso da tecnologia, carece de bons exemplos
de uso, configuração e integração do mesmo com outras linguagens de programação e sistemas. Não foram encontrados casos de sucesso na integração do Shibboleth com os sistemas Zimbra, JasperServer e Redmine, dificultando a escolha
do mesmo como solução web SSO para implantação. Vale salientar que não foi
avaliado o Shibboleth como um todo, pois está fora do escopo de solução necessitada para estre projeto. Foi analisada somente a solução web SSO oferecida pelo
módulo IdP.
8 http://www.redmine.org/
34
Dentre as soluções avaliadas, e com base nos requisitos do ambiente, o CAS
mostrou ser a melhor alternativa de ferramenta web SSO a ser utilizada neste trabalho. O CAS é uma solução bastante difundida e com vasta utilização, possuindo
diversos fóruns ativos de discussão. O CAS também oferece uma boa documentação repleta de exemplos textuais e em códigos, disponíveis para Download. Além
de oferecer bibliotecas-cliente que facilitam a sua integração com várias linguagens de programação, foram encontrados casos de sucesso da integração do CAS
com todas as ferramentas de terceiros listadas como requisito do ambiente. Outra
questão importante que favoreceu na escolha do CAS é devido a sua compatibilidade com o módulo IdP do Shibboleth.
35
4 METODOLOGIA E DESENVOLVIMENTO
Nesta seção é descrita a metodologia utilizada no trabalho a qual possibilitou que
os objetivos da pesquisa fossem alcançados. A natureza da pesquisa realizada
é aplicada através do estudo teórico acerca das ferramentas de autenticação web
SSO, modelos e escopos de autenticação disponíveis, tendo por finalidade a construção de um ambiente de autenticação centralizado no âmbito da Universidade
Federal de Lavras.
Para atender os objetivos propostos neste trabalho foi realizado um levantamento bibliográfico a respeito das ferramentas, modelos e escopos de autenticação. Em seguida foi realizada uma análise do ambiente, descrevendo o cenário
da organização no quesito da utilização de credenciais únicas na autenticação dos
sistemas, buscando identificar os pontos em que a segurança estava vulnerável. A
partir do embasamento teórico e da análise das necessidades do ambiente em estudo, foi realizada uma avaliação de soluções web SSO afim de encontrar aquela
que melhor atendesse às necessidades do ambiente. Em seguida foi realizada a implantação da solução web SSO Central Authentication Service (CAS) e posterior
integração dos sistemas ao mesmo. Nesta etapa foram realizadas alterações necessárias para que o grupo de sistemas mantidos pela DGTI integrassem ao ambiente
de autenticação centralizado.
O recurso computacional utilizado para a construção deste ambiente, foi um
servidor de autenticação em que foi instalado e configurado para atuar como central única de autenticação de diversos sistemas operantes no ambiente. A instalação deste serviço foi sobre a seguinte configuração:
Recurso físico: Servidor virtual com 4 GB de memória RAM e 100GB de
disco rígido.
Sistema Operacional: Linux Fedora Core 16.
36
Modo de autenticação: Diretório LDAP externo ao servidor.
4.1
Instalação e configuração do CAS
Nesta seção é apresentado o processo de instalação e configuração do sistema web
SSO Central Authentication Service (CAS) na DGTI.
4.1.1
Instalação
Para instalar o CAS foram seguidas as instruções do arquivo INSTALL.txt presente
no pacote de instalação obtido a partir do endereço oficial do projeto1 . O processo
de instalação do CAS é bastante simplificado, após instalar o servidor de aplicação
tomcat2 basta copiar o arquivo modules/cas-server-webapp-VERSION.war3 para
o diretório webapps do tomcat, e reiniciá-lo. Após reiniciar o tomcat, a página de
login do CAS já pode ser acessada. Embora o CAS exiba a sua página de login
quando acessado sem conexão segura configurada, um aviso é mostrado informando que a funcionalidade de SSO não está disponível, sendo necessário fazer a
devida configuração do SSL no servidor de aplicação. Após configurar o SSL no
tomcat a mensagem de aviso não é mais exibida. O CAS vem configurado com um
módulo de autenticação padrão para testes, autenticando qualquer entrada onde o
usuário e senha sejam idênticos.
4.1.2
Configuração do modo de autenticação
Como mencionado no referencial teórico, o CAS suporta múltiplas fontes simultâneas de autenticação, mas para este trabalho foi utilizado unicamente o diretório
1 http://www.jasig.org/cas
2 http://tomcat.apache.org/
3 Onde
VERSION indica a versão atual do CAS
37
LDAP oficial da DGTI. Após desabilitar este plugin de autenticação padrão, o
módulo LDAP foi configurado para autenticar-se no diretório LDAP mencionado.
Desta forma, o CAS passou a autenticar qualquer pessoa que possua vínculo ativo
com a UFLA. Para habilitar a funcionalidade de autenticação via LDAP foram
seguidas as instruções da própria documentação4 do CAS. O primeiro passo consiste na adição da dependência do módulo LDAP no arquivo pom.xml, ilustrado
pela Figura 4.1. Após adicionar a dependência, é necessário alterar o arquivo de
configuração deployerConfigContext.xml, onde são especificados os dados para
conexão ao servidor LDAP, visualizado pela Figura 4.2, e adicionada a nova fonte
de autenticação, visualizado pela Figura 4.3. Feito isso, basta reiniciar o CAS para
que as novas configurações tenham efeito.
Figura 4.1: Configuração do módulo LDAP no CAS
Figura 4.2: Parâmetros de conexão do CAS ao LDAP
4 https://wiki.jasig.org/display/CASUM/LDAP
38
Figura 4.3: Adicionando o LDAP como fonte de autenticação no CAS
4.2
Integração dos sistemas ao CAS
Nesta seção é descrito o processo de integração entre um grupo de sistemas operantes na UFLA e o CAS. Esse processo de integração pode ser divido em dois
grupos, sendo um aquele onde os sistemas desenvolvidos pela DGTI foram modificados para se adequarem ao novo modo de autenticação, e outro onde foi necessário alterar sistemas de terceiros.
Dos 19 sistemas levantados que utilizavam credencial única para autenticação,
16 são de desenvolvimento próprio da DGTI e 3 são sistemas de terceiros. Todas
as aplicações de desenvolvimento próprio e uma (MediaWiki) desenvolvida por
terceiros foram construídas utilizando linguagem de programação PHP, as outras
duas aplicações de terceiros, ZIMBRA e JasperServer, foram desenvolvidas em
JAVA.
4.2.1
Sistemas desenvolvidos pela DGTI
Ao todo, 11 sistemas foram alterados para se integrarem ao CAS. Basicamente,
somente o módulo de autenticação do usuário é alterado, o processo de autorização
permanece o mesmo. Para configurar as aplicações em PHP para autenticarem via
39
CAS, foi utilizada a biblioteca cliente phpCAS5 . A Figura 4.4 exibe um trecho
de código onde é feita a configuração de um sistema em PHP para utilizar o CAS
como fonte de autenticação, é possível notar que em nenhum momento a aplicação
possui contato direto com a senha do usuário.
Figura 4.4: Aplicação PHP utilizando a biblioteca phpCAS
Ainda na Figura 4.4, a linha 25 indica a conexão ao servidor CAS e na linha
27 mostra a configuração do certificado de segurança requerido para o phpCAS
(cliente) se comunicar com o CAS (servidor) utilizando conexão segura SSL, sem
o certificado a conexão não é estabelecida. Na linha 30 é habilitado o recurso de
SLO, sendo necessário indicar quais servidores podem enviar um pedido de logout
para este sistema, no caso foram especificados o endereço IP e o nome do servidor
CAS. Na linha 32 é chamada uma função que verifica se o usuário já se encontra
autenticado, se sim permanece na aplicação, caso contrário, a função redireciona
o usuário para a página de login do servidor CAS. Nas linhas 34 a 36 é feita a
manipulação de requisições de saída do sistema, é chamada uma função que faz o
5 https://wiki.jasig.org/display/CASC/phpCAS
40
redirecionamento do usuário a outro endereço após ser feito o seu logout no CAS.
Na linha 38 o sistema consegue recuperar o nome do usuário autenticado, com
esta informação o sistema aplica suas próprias regras de autorização, permitindo o
acesso, ou não, do usuário.
Em outros 5 sistemas optou-se por não alterar para autenticação via CAS. Em
1 deles por ser de uso crítico e possuir módulos onde grande quantidade de usuários temporários são criados a cada processo seletivo. Como esses usuários não são
criados no servidor LDAP seria necessário alterar o sistema para tratar a autenticação de modo diferente para cada grupo, ou configurar o CAS para autenticar-se
também nessa base temporária. Assim, optou-se por avaliar esta questão futuramente. Em outro sistema a dificuldade é parecida, o processo de autenticação é
diferente dependendo do usuário, sendo que alguns deles podem ser anônimos.
Dessa forma seria necessário fazer mais alterações que a substituição do módulo
de autenticação existente, ficando como tarefa para trabalhos futuros. Os outros 3
sistemas não foram integrados por terem sido considerados de uso crítico e não puderam sofrer alterações no momento, ficando também como tarefa para trabalhos
futuros. Destes 5 sistemas, 2 já encontravam-se operantes sobre conexão segura,
os outros 3 foram posteriormente configurados para tal.
4.2.2
Sistemas de terceiros
Os sistemas avaliados para utilização do CAS como servidor de autenticação foram: JasperReports Server Community6 , MediaWiki7 e ZIMBRA8 . Dos 3 sistemas,
somente o ultimo não foi integrado, o fato do mesmo utilizar uma forma de autenticação muito particular é um dificultador para este tipo de integração, ficando
também como pendência para trabalhos futuros. O ZIMBRA utiliza um esquema
6 http://community.jaspersoft.com/project/jasperreports-server
7 http://www.mediawiki.org/wiki/MediaWiki
8 http://www.zimbra.com/
41
com apelidos em que uma mesma pessoa pode autenticar-se tanto com o seu usuário real do LDAP quanto com nomes de usuários associados ao usuário verdadeiro
dentro da própria aplicação. O ZIMBRA já operava sobre conexão segura.
O JasperServer traz suporte nativo ao CAS, para integração foram seguidas as instruções contidas no site9 do próprio sistema. No arquivo de instalação do JasperServer é disponibilizado um modelo (/samples/externalAuth-sampleconfig/sample-applicationContext-externalAuth-CAS.xml) que facilita a integração.
Para integrar o sistema MediaWiki foi adquirida uma extensão disponibilizada no
site do desenvolvedor10 , após instalar a extensão e ajustar algumas configurações
o sistema foi integrado sem maiores complicações.
9 http://community.jaspersoft.com/documentation/jasperreports-server-authentication-
cookbook/configuring-jasperreports-server-cas
10 http://www.mediawiki.org/wiki/Extension_talk:CASAuthentication
42
5 RESULTADOS E DISCUSSÃO
Ao final do processo de implantação, 13 dos 19 sistemas (aproximadamente 68%),
fato ilustrado pela Figura 5.1, foram integrados ao CAS. Dos outros 6 sistemas,
os que não funcionavam com conexão segura, foram configurados para tal. Como
mencionado na seção 3.4, a solução considerada ideal é de difícil alcance devido
à diversidade nos padrões de desenvolvimento interno e fontes externas desenvolvedoras não controladas pela DGTI. Embora não tenha conseguido a configuração
Figura 5.1: Percentual de sistemas integrados ao CAS após implantação
ideal, uma boa solução intermediária foi alcançada visto que a maioria das aplicações foram integradas ao ambiente de autenticação centralizado. Na solução
alcançada, ilustrada pela Figura 5.2, a maior parte dos sistemas passaram a utilizar
um único ponto de autenticação externo a todas as aplicações. A outra parcela
continua utilizando módulo próprio para autenticar, permanecendo assim fora do
ambiente de autenticação SSO. Faz-se necessário verificar a possibilidade de inclusão de novos sistemas ao ambiente SSO, pois como existe uma falta de padrão
43
Figura 5.2: Solução alcançada com o projeto
no desenvolvimento destes sistemas, é difícil garantir a manipulação segura das
credenciais.
Vale salientar que o universo de sistemas considerado não constitui a totalidade de aplicações existentes no ambiente em estudo, visto que não foi possível
identificar sistemas externos à DGTI que fazem uso da credencial única para autenticação. Com relação aos sistemas externos, chegou-se à conclusão que devido
à dificuldade em garantir a manipulação segura das credenciais, a melhor solução
é a utilização do CAS como fonte de autenticação para todos esses casos.
Devido à disponibilização de bibliotecas-cliente para integração com o CAS, e
pela grande quantidade de exemplos facilmente encontrados, a tarefa de integração
de sistemas com o CAS é facilitada, tornando-se mais simples do que a construção
de um módulo de autenticação e uma tela de login para cada aplicação. Porém é
necessário manter a base de dados local (ou base de testes) de usuários atualizada
durante as fases de desenvolvimento e testes dos sistemas. Essa atualização é
necessária pois o CAS foi configurado para autenticar-se diretamente no diretório
LDAP oficial. Do ponto de vista da segurança na autenticação, esse esforço extra
44
em manter as bases de dados atualizadas é compensado, pois este modelo garante
a utilização de conexão segura em todos os casos, mesmo para os testes locais dos
sistemas.
E por último pode-se perceber que em algumas situações o funcionamento
do Single Logout (SLO) é indesejado. O SLO faz com que ao efetuar logout de
uma aplicação em uma aba do navegador de internet o usuário seja desconectado
também de outros sistemas, podendo gerar transtornos caso alguma operação crítica esteja em andamento. Dependendo da situação, o SLO pode ser desabilitado
no ambiente como um todo ou somente em determinadas aplicações, nestes casos,
quando desabilitado, ao efetuar o logout em uma aplicação as outras permanecerão
conectadas normalmente.
45
6 CONCLUSÃO
Durante as pesquisas, foi observado o quão delicada é a utilização de credencial
única sem os devidos cuidados e controles. Embora seja importante tanto na melhora da experiência para usuários finais quanto na simplicidade de administração,
a utilização de credencial única pode trazer enorme risco pois o comprometimento
de qualquer aplicação pode afetar diversos outros sistemas. Diante disso, foi observado que a utilização de credencial única é essencial em qualquer ambiente
onde variados sistemas requerem autenticação, mas é necessário conscientizar-se
dos riscos advindos com esta abordagem.
O presente trabalho teve por objetivo implantar uma solução para melhoria de
aspectos de segurança na utilização de credenciais únicas por sistemas web operantes no âmbito da UFLA. Para tal, foi realizado um estudo sobre ferramentas
de autenticação que possibilitassem garantir a segurança na manipulação dessas
credenciais, mesmo em um ambiente com diferentes padrões no desenvolvimento
de sistemas. Tendo como base requisitos do próprio ambiente de implantação,
algumas soluções de autenticação SSO foram avaliadas. Escolhida a ferramenta,
prosseguiu-se com sua instalação, configuração e posterior integração dos sistemas do ambiente à ferramenta de autenticação web SSO selecionada. Mesmo não
tendo êxito na completa integração dos sistemas ao ambiente SSO, foi possível
chegar a uma solução aceitável onde a maioria dos sistemas foram integrados.
Para garantir a melhora da segurança, foi necessário também efetuar a configuração de conexão segura para os sistemas que ainda não trabalhavam desta forma e
não foram integrados ao web SSO. É esperado que com o tempo novos sistemas
sejam integrados ao servidor de autenticação, evitando assim que a manipulação
de credenciais seja feita diretamente nessas aplicações. Concluiu-se também que
a utilização da central de autenticação apresenta ser a solução ideal para sistemas
46
externos não controlados pela DGTI, e que desejem também utilizar credencial
única para autenticação de seus usuários.
Como sugestão de trabalhos futuros, podem ser realizadas atividades para integração ao CAS dos 6 sistemas não integrados durante o desenvolvimento deste
trabalho. Sugere-se também a realização de atividades para inclusão da UFLA à
federação CAFe. Uma instituição pode ser integrada à essa federação em duas
formas, como provedora de identidade e/ou provedora de serviços. Tais atividades incluem a implantação dos módulos Service Provider (SP) e Identity Provider
(IdP) do Shibboleth, este último envolve também a sua integração com o CAS,
solução web SSO implantada neste trabalho.
47
REFERÊNCIAS BIBLIOGRÁFICAS
AUBRY, P.; MATHIEU, V.; MARCHAL, J. Esup-portail: open source single signon with cas (central authentication service). In: 10th International Conference of
European University Information Systems - EUNIS 2004. [s.n.], 2004. Disponível
em: <http://perso.univ-rennes1.fr/pascal.aubry/node/32>.
BHOSALE, S. Architecture of a single sign on (sso) for internet banking. In: Wireless, Mobile and Multimedia Networks, 2008. IET International Conference on.
[S.l.: s.n.], 2008. p. 103–105. ISSN 0537-9989.
BUTLER, F.; CERVESATO, I.; JAGGARD, A. D.; SCEDROV, A.; WALSTAD,
C. Formal analysis of kerberos 5. Theor. Comput. Sci., Elsevier Science Publishers
Ltd., Essex, UK, v. 367, n. 1, p. 57–87, nov. 2006. ISSN 0304-3975. Disponível
em: <http://dx.doi.org/10.1016/j.tcs.2006.08.040>.
Debora Jean Byrne, Chetan Ram Murthy, Shaw-Ben Shi e Chin-Long Shu.
Lightweight directory access protocol (LDAP) directory server cache mechanism
and method. fev. 2002. US patent 6347312.
HITACHI, H. I. S. websso. mai. 2013. Disponível em: <http://hitachi-id.com/concepts/websso.html>.
HURSTI, J. Single Sign-On. nov. 1997. Disponível em: <http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single sign-on.html>.
INTERNET2. SHIBBOLETH - A project of the Internet2 Middleware Initiative.
Oct. 2013. Disponível em: <http://shibboleth.net/>.
JASIG, C. CAS - Central Authentication Service. ago. 2013. Disponível em:
<http://www.jasig.org/cas>.
48
JOSSO. JOSSO - Java Open Single Sign-On. Oct. 2013. Disponível em: <http://www.josso.org/>.
KANT, K.; IYER, R.; MOHAPATRA, P. Architectural impact of secure socket
layer on internet servers. In: Computer Design, 2000. Proceedings. 2000 International Conference on. [S.l.: s.n.], 2000. p. 7–14. ISSN 1063-6404.
LAB, T. r. F.; FEDERATIONS tools for exploration of I. Single Logout. Oct. 2013.
Disponível em: <https://fed-lab.org/best-practises/single-logout/>.
LEE, D.; JANG, H. S.; KIM, K. C. A lightweight protocol based on the ssl protocol
for handheld devices. In: Information Science and Applications (ICISA), 2011
International Conference on. [S.l.: s.n.], 2011. p. 1–4.
MIT. Kerberos: The network authentication protocol. nov. 2012. Disponível em:
<http://web.mit.edu/kerberos/www/>.
MIT. MIT KERBEROS CONSORTIUM. oct. 2013. Disponível em: <http://www.kerberos.org>.
MORGAN, R. L.; CANTOR, S.; CARMODY, S.; HOEHN, W.; KLINGENSTEIN, K. Federated security: The shibboleth approach. Educause Quarterly, v. 27,
n. 4, p. 12–17, 2004. ISSN 1528-5324. Disponível em: <http://www.editlib.org/p/103716>.
NIE, F.; XU, F.; QI, R. Saml-based single sign-on for legacy system. In: Automation and Logistics (ICAL), 2012 IEEE International Conference on. [S.l.: s.n.],
2012. p. 470–473. ISSN 2161-8151.
OASIS. OASIS - advancing open standards for the information society. Oct. 2013.
Disponível em: <https://www.oasis-open.org>.
PERKINS, S. Internet cookies: Security implications. In: Online]. Available: citeseer.ist.psu.edu/perkins00internet.html. [S.l.: s.n.], 2000.
49
RANUM, M. J.; AVOLIO, F. M. A toolkit and methods for internet firewalls. In:
In Proc. Summer 1994 USENIX Conference. [S.l.: s.n.], 1994. p. 37–44.
SARS, C. Unified Single Sign-On. nov. 1998. Disponível em: <http://www.tml.tkk.fi/Opinnot/Tik-110.501/1998/papers/3singlesignon/singlesign-on.htm>.
SWITCHAAI. Authentication and Authorization Infrastructure. mai. 2013. Disponível em: <http://www.switch.ch/aai>.
VOLCHKOV, A. Revisiting single sign-on: a pragmatic approach in a new context.
IT Professional, v. 3, n. 1, p. 39–45, 2001. ISSN 1520-9202.
WEI, K.; MUTHUPRASANNA, M.; KOTHARI, S. Preventing sql injection attacks in stored procedures. In: Software Engineering Conference, 2006. Australian. [S.l.: s.n.], 2006. p. 8 pp.–. ISSN 1530-0803.
50
7 GLOSSÁRIO
Cookie: De acordo com (PERKINS, 2000), um cookie pode ser definido como
sendo uma informação armazenada, pelo navegador, em formato texto no disco
rígido do usuário. Desta forma é possível que sites da web armazenem
informações no computador do usuário para consultas futuras.
Firewall: Um firewall é um sistema, ou conjunto deles, que tem o objetivo de
prover um ponto de defesa, auditado e controlado, para acesso a serviços. Sendo
que essas requisições de acesso podem partir tanto de uma rede privativa interna
quanto de redes externas (RANUM; AVOLIO, 1994).
LDAP: Lightweight directory access protocol (LDAP) é um protocolo baseado
no modelo de arquitetura cliente-servidor. O cliente se conecta e envia
requisições ao servidor LDAP, que por sua vez, processa tais consultas e responde
ao cliente (BYRNE et al., 2002).
SQL-Injection: É um tipo de ataque que, devido a falta de validação adequada
aos parâmetros de entrada do sistema, o invasor consegue acesso direto à base de
dados (WEI; MUTHUPRASANNA; KOTHARI, 2006).
SAML: Security Assertion Markup Language (SAML)é um framework baseado
em XML1 utilizado para troca de informações sobre autenticação, autorização e
atributos de usuários (OASIS, 2013). A primeira versão do SAML foi lançada
pelo comitê técnico de serviços de segurança do OASIS2 em novembro de 2002,
atualmente o framework encontra-se na versão 2.0. De acordo OASIS (2013),
SAML possibilita que entidades (organizações) confirmem informações de
1 http://www.w3schools.com/xml/
2 https://www.oasis-open.org
51
identidade, atributos e direitos de um usuário a outras entidades (aplicações locais
ou externas). Segundo Nie, Xu e Qi (2012), SAML é utilizado para troca de
informações de autenticação e atributos entre diferentes domínios de segurança.
SSL: Secure Sockets Layer (SSL) é um protocolo amplamente utilizado que
permite a troca de informações, de forma segura, por aplicações cliente/servidor
(KANT; IYER; MOHAPATRA, 2000).