Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf ·...
Transcript of Um esquema de autenticação segura para o Squid proxy-cache ...john/files/monografia_final.pdf ·...
UNIVERSIDADE SAO FRANCISCOCurso de Ciencia da Computacao
JOHN LENON CARDOSO GARDENGHI
UM ESQUEMA DE AUTENTICACAO SEGURA PARA OSQUID PROXY-CACHE: UM ESTUDO DE CASO BASEADO
EM NOVELL(R) EDIRECTORY(TM)
Itatiba2011
JOHN LENON CARDOSO GARDENGHI - R.A. 002200800362
UM ESQUEMA DE AUTENTICACAO SEGURA PARA OSQUID PROXY-CACHE: UM ESTUDO DE CASO BASEADO
EM NOVELL(R) EDIRECTORY(TM)
Monografia apresentada ao Curso de Cienciada Computacao da Universidade Sao Francisco,como requisito parcial para a obtencao do tıtulode Bacharel em Ciencia da Computacao.
Orientador: Prof. Marcelo Augusto GoncalvesBardi
Itatiba2011
Ao meu pai, que sempre
investiu e acreditou em mim.
AGRADECIMENTOS
Agradeco, acima de tudo, a Deus, pela forca e coragem que recebi de sua parte e pela
alegria proporcionada pelos frutos destes anos de trabalho.
Ao Prof. Marcelo Augusto Goncalves Bardi, meu orientador e amigo, por seus valiosos
conselhos e sugestoes no decorrer deste projeto, que sem duvida foram essenciais para sua
concretizacao e que levarei como exemplo para minha carreira profissional.
Aos demais professores do curso de Ciencia da Computacao, cuja colaboracao foi
indispensavel para que este projeto se tornasse realidade.
Por fim, aos bons amigos que tive o fortunio de conhecer ao longo destes anos que
passei na Universidade Sao Francisco, todo o esforco dispendido por todos nos, em contraste
ao nosso animo e vontade, estarao sempre em minhas lembrancas.
RESUMO
O processo de identificacao de um usuario em ambientes de rede e muito importante, ja que
consiste em conhecer quem esta utilizando um recurso e, assim, agrega seguranca e inte-
gridade ao ambiente, permitindo seu uso controlado. Entretanto, a diversificacao de recursos
em rede implica no emprego de varias, e muitas vezes distintas, credenciais por um mesmo
usuario, o que significa uma desvantagem do ponto de vista de usabilidade. Uma solucao
potencial para este problema sao sistemas de autenticacao Single Sign-On (SSO), em que
usuarios se autenticam apenas uma vez e sao automaticamente autorizados a acessar to-
dos os demais recursos que precisam. Neste contexto, a proposta deste trabalho consiste
em desenvolver um esquema de autenticacao segura para o Squid proxy-cache, com forte
apoio na estrategia SSO, com o principal objetivo em otimizar usabilidade e seguranca no uso
deste recurso de rede. Um estudo de caso aplicado a redes Novell foi feito, um ambiente fa-
voravel para o desenvolvimento do mecanismo de autenticacao SSO. Por fim, uma interface
de autenticacao segura foi implementada, baseada em uma base de usuarios com suporte a
LDAP e estudada tambem para o caso particular de rede Novell. Com isso, um sistema de
autenticacao seguro customizavel para o Squid foi desenvolvido, eliminando a interacao direta
do proxy-cache com o usuario.
Palavras-chave: autenticacao. single sign-on. Squid proxy-cache. Novell eDirectory.
ABSTRACT
The identification process in network environments is a very important issue, it consists of
knowing who is using a resource and thereby it aggregates security and integrity to this envi-
ronment, enabling its controlled use. However, the diversification of network resources implies
in the use of many distinct credentials by a same user, which means a disadvantage from the
usability point of view. A potential solution for this problem is Single Sign-On (SSO), a me-
chanism whereby users authenticate themselves only once and are automatically authorized
to access any further resource they need. In this context, the proposal of this work consists of
developing an scheme of secure authentication for Squid proxy-cache, with strong support in
SSO strategy, with the main goal in optmize usability and security in the use of this resource. A
case study applied to Novell networks was done, a favorable environment to the development of
SSO mechanism. Finally, a secure interface was implemented, it was based in any LDAP user
database, particularly studied for Novell network’s use case. Thereat, a customizable secure
authentication system for Squid was developed, eliminating the direct interation between the
proxy-cache system and the end user.
Key words: authentication. single sign-on. Squid proxy-cache. Novell eDirectory.
Lista de Figuras
FIGURA 1 Ambiente de Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . 16
FIGURA 2 Esquema de autenticacao descentralizada . . . . . . . . . . . . . . . . 17
FIGURA 3 Pseudo-SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
FIGURA 4 SSO verdadeiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
FIGURA 5 Soquetes de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
FIGURA 6 Janela para autenticacao no navegador de internet . . . . . . . . . . . 26
FIGURA 7 Esquema geral da solucao proposta . . . . . . . . . . . . . . . . . . . . 28
FIGURA 8 Diagrama de classes do Servidor SSO . . . . . . . . . . . . . . . . . . 30
FIGURA 9 Interface de logon do Novell Client . . . . . . . . . . . . . . . . . . . . . 33
FIGURA 10 Icone de bandeja do Cliente SSO . . . . . . . . . . . . . . . . . . . . . 33
FIGURA 11 Informacoes do certificado no navegador de internet . . . . . . . . . . . 40
FIGURA 12 Diagrama de sequencia para acesso a internet com SSO . . . . . . . . 42
FIGURA 13 Diagrama de sequencia para acesso a internet sem SSO . . . . . . . . 42
FIGURA 14 Capturas do Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Lista de Siglas
API Application Programming Interface
ASP Authentication Service Provider
DIB Directory Information Base
DIT Directory Information Tree
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICP Internet Cache Protocol
ISP Internet Service Provider
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LDAPS Lightweight Directory Access Protocol over SSL
MD5 Message-Digest algorithm 5
NDS Novell Directory Services
NIS Network Information Service
NNS Netware Name Service
NSF National Science Foundation
NTLM NT Lan Manager
OTP One-Time Password
PAM Pluggable Authentication Modules
PIN Personal Identification Number
POP3 Post Office Protocol Version 3
RMI Remote Method Invocation
RPC Remote Procedure Call
SASL Simple Authentication and Secure Layer
SMB Server Message Block
SSL Secure Sockets Layer
SSO Single Sign-On
TCP Transmission Control Protocol
UDP User Datagram Protocol
WAN Wide Area Network
Sumario
1 INTRODUCAO 10
2 DESENVOLVIMENTO 122.1 FUNDAMENTACAO TEORICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.1.1 Fatores de seguranca . . . . . . . . . . . . . . . . . . . . . . . . 122.1.1.2 Controle de acesso . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.1.3 Terminologia de infraestrutura de autenticacao . . . . . . . . . . 15
2.1.2 Evolucao de sistemas de autenticacao . . . . . . . . . . . . . . . . . . . . 162.1.3 Sistemas de autenticacao SSO . . . . . . . . . . . . . . . . . . . . . . . . 182.1.4 Servicos de diretorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.5 Sistema proxy-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.6 Comunicacao interprocessos . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.7 Aplicacao cliente-servidor: soquetes de rede . . . . . . . . . . . . . . . . 24
2.2 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.1 O problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.3 Solucao proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.3.1 O servidor SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3.2 O cliente SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.3.3 A interface web para logon do usuario . . . . . . . . . . . . . . . 342.2.3.4 A interface de comunicacao com o Squid . . . . . . . . . . . . . 34
2.2.4 Preparacao do ambiente computacional . . . . . . . . . . . . . . . . . . . 352.2.4.1 Configurando o Squid e o Servidor SSO . . . . . . . . . . . . . 352.2.4.2 Configurando o Apache . . . . . . . . . . . . . . . . . . . . . . . 372.2.4.3 Consideracoes desta implementacao . . . . . . . . . . . . . . . 40
2.3 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 CONCLUSOES 44
REFERENCIAS 45
APENDICES 46
A Script Perl para comunicacao com o Squid 47
B Arquivo de configuracao do Squid 48
C Arquivo de configuracao vhost-ssl.conf 49
D Capturas do Wireshark 50
10
1 INTRODUCAO
Assim como na vida real temos uma identidade, unica, que nos distingue das demais
pessoas e elementos, o uso de recursos1 em rede tambem requer uma identificacao de quem
esta solicitando servicos. Essa identificacao e importante pois deve-se conhecer quem esta
solicitando acesso de forma a aplicar de regras de acesso, permissoes e registro de acoes.
A maneira mais comum de identificacao e a autenticacao. Autenticacao e o processo de
verificacao que compara uma entrada do usuario (dita credenciais) com dados de identificacao
armazenados eletronicamente, supostamente associados biunivocamente. Se as credenciais
apresentadas forem validas, entao e concedido acesso ao recurso solicitado para o usuario
autenticado, conforme polıticas de acesso. O metodo mais simples de autenticacao que
existe e a apresentacao do par usuario e senha, entretanto metodos mais sofisticados sao
constantemente desenvolvidos e aprimorados, como identificacao por biometria e tokens de
autenticacao.
Entretanto, em um ambiente de rede, a diversificacao de recursos implica um conjunto
de credenciais para um unico usuario, cada uma concedendo acesso a um recurso especıfico.
Esse gerenciamento de identidades tornou-se um problema crıtico, amplamente discutido atu-
almente. A saıda mais comum, adotada hoje em dia, e o uso das mesmas credenciais para
todos os recursos, e a saıda mais simples e aplicavel, um trade off entre seguranca e usabili-
dade.
Uma solucao potencial para o problema em questao e o Single Sign-On (SSO). SSO e
uma tecnica em que um usuario se autentica apenas uma vez e e automaticamente autorizado
a outros sistemas que requerem autenticacao, sem a necessidade de interacao manual [1, 2].
Seu uso aumenta a usabilidade em rede, diminui erros humanos e centraliza o gerenciamento
de usuarios.
Neste trabalho, sera abordado o problema de autenticacao para um sistema proxy-
cache, do ponto de vista de usabilidade e seguranca. A proposta e implementar um sistema
de autenticacao que englobe a estrategia SSO e um mecanismo de autenticacao seguro con-
tra uma base de usuarios com suporte a LDAP, de forma a funcionar como um auxiliador
de autenticacao externo para o Squid proxy-cache. Como caso de uso, essa proposta sera
implementada em redes Novell, todavia seu uso pode ser facilmente adaptado para outras in-1Neste trabalho, um recurso pode ser qualquer entidade de rede que prove algum tipo de servico ao usuario –
por exemplo, instant messenger, e-mail, sistema de arquivos e sistemas ERP – e qualquer informacao que agregue
valor ao negocio ou finalidade em questao.
11
fraestruturas. Com isso, o objetivo principal deste trabalho e implementar um sistema capaz de
prover autorizacao transparente ao proxy-cache Squid baseado nas credenciais de usuarios
do sistema de diretorios Novell eDirectory.
Nesse contexto, almeja-se desenvolver um sistema cliente-servidor de autenticacao
single sign-on capaz de:
• Fazer a autorizacao SSO de usuarios autenticados na Novell;
• Oferecer uma interface de autenticacao segura para usuarios nao autenticados na Novell,
com consulta de validacao de credenciais na propria base de usuarios da Novell.
12
2 DESENVOLVIMENTO
2.1 FUNDAMENTACAO TEORICA
Este trabalho engloba aspectos teoricos e uso de ferramentas que valem ser detalha-
das. Essa secao objetiva apresentar este detalhamento, que servira como base e motivacao
para o entendimento da proposta e desenvolvimento deste trabalho. Nas Secoes 2.1.1 a 2.1.3,
sao apresentados conceito referentes a sistemas de autenticacao, que serao usados durante
o decorrer desde projeto. Nas Secoes 2.1.4 a 2.1.7, sao apresentadas ideias inerentes as
ferramentas que serao usadas no desenvolvimento deste projeto, isto e, tecnologias para com-
putadores em rede.
2.1.1 Autenticacao
Como ja introduzido na Secao 1, o processo de autenticacao e muito importante em
um ambiente de rede. Nesta secao, serao apresentados alguns conceitos com relacao ao
processo de autenticacao do ponto de vista de seguranca e algumas terminologias que serao
utilizadas adiante.
2.1.1.1 Fatores de seguranca
Do ponto de vista de seguranca, autenticacao e essencial. Em um ambiente de rede,
um recurso e um fator crucial por representar alguma especie de valor para o negocio ou
finalidade de uso em questao. Neste contexto, o recurso possui um dono, que pode ser
um indivıduo ou um grupo de indivıduos. Compete a gestao de seguranca e tecnologia da
informacao a protecao deste, de forma que apenas indivıduos autorizados sejam capazes de
ter acesso ao recurso desejado. Em geral, a protecao de recursos e fundamentada em tres
pilares [3]:
1. Confidencialidade: cuida para que o recurso nao seja acessıvel para indivıduos ou
grupos de indivıduos nao autorizados;
2. Integridade: garante que o recurso esteja ıntegro, isto e, nao seja alterado acidental ou
intencionalmente de forma que perca sua validade;
13
3. Disponibilidade: o recurso deve estar acessıvel sempre que houver necessidade do
usuario.
Portanto, um ambiente seguro ideal seria aquele que atendesse a esses tres requisitos
sem falhas ou ameacas. Qualquer ameaca a um desse fatores e chamada de risco. Por
conseguinte, e necessario que profissionais de seguranca conhecam bem as necessidades
de seguranca do ponto de vista desses tres requerimentos e, da mesma forma, conheca os
riscos associados.
Vale destacar que todos os fatores de seguranca apresentados nessa secao baseiam-
se no uso de recursos por indivıduos definidos. Ao processo que analisa requisicoes e as
valida a fim de tomar a decisao de concessao da-se o nome de controle de acesso.
2.1.1.2 Controle de acesso
O controle de acesso e o principal fator na protecao de recursos. E atraves dele que
e possıvel conceder ou declinar acesso ao recurso solicitado. Em geral, o controle de acesso
compreende tres processos [3]: autenticacao, autorizacao e auditoria, que serao expostos
a seguir.
Autenticacao
Como a grande maioria das entidades em computacao, um usuario e abstraıdo em um
objeto que o identifique, caracterizado por um identificador de usuario (ID de usuario). Um ID
de usuario e associado a um unico usuario, e o objeto abstrato, em geral, possui informacoes
deste (como nome, telefone e caracterısticas pertinentes ao sistema em questao). A partir
deste objeto que a autenticacao e feita e, da mesma maneira, o controle de acesso.
O processo de autenticacao e composto por duas etapas [3]: identificacao e
autenticacao em si.
A identificacao consiste em dar uma identidade ao usuario que esta se autenticando.
Essa identidade e o proprio ID do usuario. Nesta etapa, o sistema de autenticacao procura por
todos os objetos e identifica o usuario tendo em vista os privilegios com relacao ao recurso
que ele esta solicitando acesso.
A autenticacao em si, por sua vez, valida a identificacao do usuario feita na etapa
anterior. Essa validacao e feita atraves da apresentacao de uma evidencia que certifica que
essa pessoa que esta solicitando acesso em nome deste usuario identificado e realmente o
14
dono desta identificacao. Essa evidencia e chamada credencial e pode ser:
• Algo que o usuario sabe: e um segredo compartilhado entre as duas partes (usuario e
recurso). O mais comum e o par usuario e senha, mas temos outras formas como os
PINs (Personal Identification Number).
• Algo que o usuario possui: e baseado em uma posse do usuario, certificado pela auto-
ridade de autenticacao. Como exemplos, vale citar chaves de carro, tokens, que geram
uma OTP (One-time Password) ou qualquer outro mecanismo que exija a posse de um
dispositivo ou codigo dinamico.
• Algo que o usuario e: consiste na autenticacao embasada na biometria do solicitante,
como impressao digital, analise de voz, reconhecimento de face, retina e ıris, e qualquer
outra estrategia que use de caracterısiticas fısicas do usuario.
Autorizacao
A autorizacao e o processo de conceder acesso a um determinado recurso para um
usuario ja identificado e autenticado, portanto, e responsavel por prover acesso autenticado
ao recurso solicitado.
Do ponto de vista pratico, as fases de autenticacao e autorizacao nao sao tao distin-
tas. Em linhas gerais, a autenticacao compete apurar a identidade do cliente, enquanto a
autorizacao compete determinar permissoes de acesso frente a identidade, ja validada, do
solicitante.
Diante dessa interdependencia, o padrao que sistemas operacionais e aplicacoes em
geral costumam seguir e o processo de logon do usuario. Neste metodo, o usuario fornece
suas credenciais, iniciando o processo de autenticacao. Depois de autenticado, a aplicacao
gera um estrutura para este usuario, chamado de token de acesso. Sempre que o usuario
solicitar acesso a um recurso dentro da aplicacao, ela verifica o token do usuario e faz o
controle de acesso, constituindo o processo de autorizacao. Assim, o token de acesso e a
interface entre autorizacao e autenticacao, pois ele e gerado na fase de autenticacao e usado
nas fases de autorizacao.
Auditoria
A partir do momento que um usuario e autenticado e autorizado a acessar um recurso,
15
e necessario que este recurso proveja um mecanismo de registro de acoes do usuario, para
que seja possıvel saber de que maneira esses clientes estao usando o recurso. Por outro lado,
e necessario ainda que este recurso seja capaz de registrar tentativas de acesso indevidos.
Neste contexto, a funcao da auditoria e registrar todas as acoes dos usuarios diante de
um recurso. Do ponto de vista de seguranca, a auditoria e muito importante, pois e ela que
possibilita determinar os acessos (devidos e indevidos) ao recurso e registrar as acoes dos
usuarios autenticados.
2.1.1.3 Terminologia de infraestrutura de autenticacao
No processo de autenticacao, geralmente temos envolvidas as seguintes partes [3]:
Solicitante e a parte que provera suas credenciais. Pode ser uma pessoa ou um software,
geralmente referidos como cliente ou usuario.
Autenticador e a parte que prove recursos ao solicitante, por isso precisa validar sua identi-
dade. Em geral, e dito servidor.
Autoridade/Banco de Seguranca e a parte que contem as informacoes de credenciais e,
muitas vezes, os mecanismos de identificacao e autenticacao. Pode ser desde um ar-
quivo, um sistema de diretorios, uma base centralizada de usuarios ou um conjunto de
servidores de autenticacao.
Desta forma, de De Clercq [1], encontramos as seguintes terminologias de autenticacao:
Servidores de Autenticacao sao as maquinas que realizam tarefas de autenticacao, diz res-
peito a parte fısica;
Autoridades de Autenticacao sao as entidades confiaveis que fazem a autenticacao em si,
diz respeito a parte logica;
Infraestrutura de Autenticacao e o conjunto de servidores e autoridades de autenticacao,
diz-se que esse conjunto prove os servicos de autenticacao.
Em um ambiente de rede, cada recurso que exige identificacao possui uma autoridade
de autenticacao associada. Como exemplo, podemos citar domınios de rede (em arquiteturas
Windows, cuja autoridade de autenticacao e o servidor Active Directory) ou uma arvore (em
arquitetura Novell, cuja autoridade de autenticacao e o servidor Novell eDirectory).
Em um processo de autenticacao padrao, o usuario submete suas credenciais a autori-
dade de autenticacao, que ira validar tais credenciais baseada em seu banco de usuarios. Se
16
FIGURA 1: Ambiente de Autenticacao. Nesta ilustracao, podemos destacar a infraestrutura de
autenticacao, composta por um servidor de autenticacao e uma autoridade de autenticacao
(Novell eDirectory).
as credenciais forem validadas, entao diz-se que elas sao autenticas, e ao usuario e conce-
dido acesso ao recurso solicitado conforme permissoes de controle de acesso e processos de
autorizacao. Em geral, autoridades de autenticacao cedem ao usuario um token que o identi-
fica como usuario autenticado. Vale destacar que o processo de autenticacao apenas concede
ou nega acesso a um determinado recurso, mas nao dispoe regras de acesso. As regras de
acesso sao filtros que, a partir de uma credencial, determina o que um usuario pode ou nao
fazer com o recurso a que se autenticou. O processo de autenticacao e ilustrado na Figura 1.
2.1.2 Evolucao de sistemas de autenticacao
Quando sistemas de computadores foram introduzidos, a computacao era centralizada,
isto e, os usuarios usavam terminais conectados a computadores centrais, os chamados main-
frames. Nesta fase, a autenticacao era feita de forma centralizada, o unico computador “inte-
ligente” era o computador central. Com o passar dos anos, a computacao foi evoluindo e
microcomputadores foram sendo incorporados a uma rede computadores, que se comunica-
vam entre si por protocolos de redes, como o TCP/IP. Com isso, o esquema de autenticacao
foi mudando, tornando-se descentralizado, pois os recursos em rede foram sendo distribuıdos
e seu uso, se diversificando. Deste modo, para cada recurso a que o usuario precisava ter
acesso, ele tinha uma credencial associada.
Diante disso, muitos sistemas de autenticacao foram criados. Um boa referencia nesta
area e o livro do Todorov [3]. Em linhas gerais, os sistemas de autenticacao dividiram-se em
dois grandes grupos: sistemas de autenticacao centralizados e descentralizados.
17
Os sistemas de autenticacao descentralizados surgiram gracas a diversificacao de
recursos em rede. Neste modelo, cada recurso possui sua propria base de usuarios para
autententicacao e polıticas de controle de acesso.
FIGURA 2: Esquema de autenticacao descentralizada.
O sistema de autenticacao descentralizado apresenta sua primeira desvantagem do
ponto de vista de usabilidade. Um mesmo usuario precisa ter uma porcao de credenciais e
se autenticar para todos os recursos aos quais precisa ter acesso. Alem disso, se o usuario
quiser manter a mesma senha para todos os recursos, por exemplo, ele precisa mudar todas
quando mudar alguma delas. Do ponto de vista de administracao, a descentralizacao tambem
nao apresenta vantagens, pois ha varias bases de usuarios distintas a serem mantidas.
Sistemas de autenticacao centralizados, por sua vez, possuem toda a base de usuarios
e polıticas centralizadas em uma unica autoridade de autenticacao. A grande vantagem disso
e que os clientes se autenticam apenas uma vez para ter acesso a todos os recursos. Aos
administradores, por sua vez, a manutencao e facilitada, visto que ha apenas uma base a ser
gerenciada. Do ponto de vista de seguranca, sistemas de autenticacao centralizados apre-
sentam a desvantagem de que, se uma entidade mal intencionada descobre as credenciais de
um usuario, por ser unica, essa entidade tera acesso a todos os recursos disponıveis a esse
usuario. A centralizacao e um nome generico para sistemas de autenticacao Single Sign-On
(SSO), e o que sera apresentado na proxima secao.
18
2.1.3 Sistemas de autenticacao SSO
O Open Group [4] define SSO como sendo o mecanismo pelo qual uma unica acao de
autenticacao e autorizacao do usuario concede acesso a todos os computadores e sistemas
aos quais ele tem acesso, sem a necessidade de fornecer multiplas senhas.
Por ser um metodo muito interessante por representar um bom trade-off entre seguranca
e usabilidade, muitos sistemas de autenticacao SSO surgiram. Nesta secao, sera apresentado
uma classificacao basica de sistemas SSO, baseada na taxonomia desenvolvida em Pashala-
dis e Mitchell [2].
Essencialmente, temos dois tipos de sistemas SSO: pseudo-SSO e SSO verdadeiro.
O pseudo-SSO e um sistema que apenas executa os mecanismos de autenticacao
dos recursos aos quais prove acesso a partir das credenciais armazenadas, ditas identidades
SSO. Neste caso, o usuario efetua a autenticacao no sistema pseudo-SSO, dita autenticacao
primaria, e, cada vez que acessa um recurso em rede, e autenticado automaticamente pelo
pseudo-SSO. Esse esquema de autenticacao implica que o sistema pseudo-SSO armazena
identidades para acesso a recursos especıficos, portanto, deve armazenar, no mınimo, n iden-
tidades para acesso a, no maximo, n recursos. Por isso, a relacao entre identidade e recurso
e dita n : 1: e necessario uma ou mais identidade(s) no pseudo-SSO para acesso a um unico
recurso. A autenticacao pseudo-SSO e ilustrada na Figura 3.
FIGURA 3: Pseudo-SSO.
O SSO verdadeiro, por sua vez, e constituıdo por entidades chamadas ASP (Authen-
tication Service Providers). O ASP possui uma integracao com recursos aos quais provera
acesso, dada por uma comunicacao segura; neste caso, ao contrario do pseudo-SSO, o
unico processo de autenticacao que e feito e entre o usuario e o ASP. O ASP, por sua vez,
apenas notifica ao recurso em questao sobre a autenticacao do usuario, dito declaracao de
19
autenticacao. Com isso, a relacao entre identidade e recurso e dita n : m, isto e, alem de
poder existir varias identidades SSO para um unico recurso, como e o caso do pseudo-SSO,
e possıvel ainda que o ASP use a mesma identidade SSO para prover acesso a mais de um
recurso. O metodo SSO verdadeiro e ilustrado na Figura 4. Por ser responsavel pelo arma-
zenamento das identidades, em geral um ASP armazena as credenciais de maneira segura,
usando criptografia, por exemplo.
FIGURA 4: SSO verdadeiro.
2.1.4 Servicos de diretorio
Ate agora, foram discutidos metodos de protecao e autenticacao para uso de recursos
em rede. Tendo em vista o foco deste trabalho, onde serao usados servicos de diretorios,
em particular o Novell eDirectory, como autoridades de autenticacao e o recurso alvo sera
o Squid proxy-cache, nesta e na proxima secao serao apresentados conceitos referentes a
essas estruturas, onde apresentamos as ferramentas abordadas neste trabalho.
Um diretorio e um repositorio de informacoes sobre objetos, organizados segundo um
criterio que facilite sua consulta [5]. A definicao de diretorio e muito ampla, nao se restringe
ao escopo deste trabalho, mas possui aplicacoes diversas. Em geral, um diretorio contem
informacoes diversas sobre um usuario, e pode ser aplicado em varios contextos. Por exem-
plo, vamos considerar um site de e-commerce. Na segunda vez que e acessado, podemos
perceber que o site comeca a construir paginas personalizadas para o usuario, baseado em
seus interesses de compra. Isso e feito porque o site obtem informacoes do usuario a par-
tir dos cookies armazenados de navegacoes anteriores e, a partir de informacoes sobre este
usuario armazenadas em seu diretorio constroi uma pagina personalizada.
O servico de diretorio [5, 6], por sua vez, e uma entidade de gerenciamento seguro
20
de informacoes interrelacionadas entre si, suporta a replicacao de informacoes e e otimizado
para busca e leitura. Na pratica, servicos de diretorios provem uma tecnologia poderosa de
gerenciamento de dados, oferecendo administracao centralizada e replicacao das informacoes
em um ambiente de computacao distribuıda. Alem disso, a informacao e organizada de ma-
neira hierarquica e armazenada de maneira segura. O tipo de informacao armazenada em um
diretorio varia de acordo com sua aplicacao. No contexto de autenticacao e rede de computa-
dores, o diretorio armazena informacoes sobre pessoas, grupos, recursos e servicos.
Um servico de diretorio e composto, basicamente, por alguns elementos:
Objeto e o item mais simples do diretorio, e uma estrutura de dados, com atributos (ou pro-
priedades) e sintaxe proprios que define as entradas de dados do diretorio;
Esquema define, internamente, o conteudo do diretorio. Define, ainda, as propriedades de
objetos e a sintaxe que define seus valores. Por fim, o esquema determina como o
diretorio e estruturado;
DIT do ingles, Directory Information Tree, ou simplesmente arvore do diretorio, e a organizacao
hierarquica das informacoes em um diretorio. Existem objetos em um diretorio que sao
ditos conteineres, sao responsaveis por agrupar outros objetos do diretorio e constituem
os nos da arvore do diretorio. A DIT prove uma organizacao logica e visual dos objetos
que facilitam a administracao do diretorio.
DIB do ingles, Directory Information Base, a DIB e o banco de dados que contem as
informacoes do diretorio armazenadas. A DIB e dividida em particoes, para suportar
diretorios geograficamente distribuıdos e melhorar o desempenho de busca e leitura.
Por isso, servicos de diretorios suportam replicacao de dados, onde as DIBs sao copi-
adas para multiplos servidores de diretorio. A replicacao e importante pois aumenta a
tolerancia a falhas pela redundancia e melhora o desempenho de busca em sistemas
distribuıdos (visto que servidores geograficamente distribuıdos possuem uma copia dos
dados do diretorio).
Com a popularizacao dos sistemas de diretorios e sua grande utilidade, muitas
aplicacoes foram surgindo desde meados dos anos 1990. Como exemplos, podemos citar
o Microsoft Active Directory, o ApacheDS, o OpenLDAP, o Open Directory, entre outros. Neste
trabalho, vamos abordar o Novell eDirectory.
O Novell eDirectory e um servico de diretorio muito usado atualmente e amplamente
desenvolvido. Antes de sua introducao em 1993 no Novell Netware 4.0, a Novell usava um
21
servico de gerenciamento de usuarios, nao tao complexo, chamado bindery, que nao supor-
tava nem replicacao de dados. Com o crescimento do uso de redes, a Novell lancou um add-on
para o Netware 3.0 chamado NNS (Netware Name Services), em 1990, agregando replicacao
e sincronizacao de dados entre grupos de servidores bindery chamados de domınio. Entre-
tanto, o NNS apresentava uma serie de deficiencias e limitacoes. Em 1993, a Novell intro-
duziu o chamado NDS (Netware / Novell Directory Services), substituindo o NNS em 1994
e tornando-se, com o passar dos anos, uma ferramenta robusta para gerenciamento de di-
retorios. Em 2001, com o lancamento da versao 8, o NDS passou a chamar-se simplesmente
eDirectory.
Atualmente, o eDirectory apresenta o grande diferencial dos demais servicos de di-
retorios por ter sido portabilizado para rodar em varias plataformas. Hoje, em sua versao 8.8
SP6, funciona perfeitamente em Windows, Netware, Linux e Solaris.
2.1.5 Sistema proxy-cache
Um sistema proxy-cache – ou web cache – e uma entidade de rede que responde
por solicitacoes HTTP no lugar de um servidor Web [7]. E geralmente instalado em um ISP
(Internet Service Provider). Por exemplo, em uma empresa, instala-se um servidor proxy-cache
em sua sede e configura-se todos os browsers para usar este servidor. O mesmo acontece
em um ISP maior, como a Telefonica, por exemplo. O servidor proxy armazena solicitacoes
Web localmente. Essa armazenacao local e chamada de caching, por isso e dito proxy-cache,
pois armazena um cache de todas as respostas de solicitacoes que recebe.
O uso de um servidor proxy se da mediante a configuracao no browser do cliente.
Uma vez configurado, todas as solicitacoes HTTP serao encaminhadas ao servidor proxy ao
inves de ser encaminhada diretamente ao servidor web. Ao receber uma solicitacao HTTP, o
proxy verifica se nao possui o objeto solicitado armazenado localmente em seu cache. Se ele
possuir o objeto, entao retorna-o ao cliente atraves de uma resposta HTTP, senao ele obtem
o objeto atraves de uma conexao TCP (Transmission Control Protocol) com o servidor web em
questao e encaminha o objeto ao cliente, que apenas se conecta com o servidor proxy. Vale
ressaltar que, neste ultimo caso, o proxy armazena uma copia do objeto recebido antes de
reencaminhar para o cliente, construindo assim seu cache. Nesse contexto, cabe dizer que o
proxy atua ora como servidor, quando responde as solicitacoes HTTP de clientes, e ora como
cliente, quando obtem objetos atraves da conexao TCP com servidores web.
As vantagens de se utilizar um proxy-cache em uma rede sao evidentes. Uma porque
22
eventualmente reduz o tempo de resposta de uma requisicao HTTP de um cliente, caso te-
nha o objeto requisitado em seu cache, isso devido a velocidade de conexao em uma rede
LAN (Local Area Network) ser muito superior a da rede WAN (Wide Area Network). Outra e
consequencia direta da primeira: ha com isso uma reducao substancial do fluxo de acesso a
internet, otimizando assim o uso da banda e aumentando o desempenho de aplicacoes que
usam a internet.
Atualmente, sistemas proxy-cache, alem de prover a funcionalidade de web caching,
tambem oferecem mecanismos de controle de acesso, baseado na autenticacao de usuarios.
Com isso, varias vantagens surgem, desde princıpios legais, onde uma empresa, por exemplo,
pode impedir o uso de seu recurso de internet para acesso a conteudos inapropriados, ate re-
gistro de acessos, onde e possıvel, ao administrador de rede, acompanhar o que cada usuario
acessa, o tempo de conexao, a banda consumida, entre outros.
Um dos sistemas mais usados e o Squid [8, 9, 10], um proxy-cache para HTTP 1.0 com
recursos de controle de acesso, autorizacao e registro de acesso, atualmente em um projeto
coordenado por Duane Wessels, que e o desenvolvedor e esta envolvido desde o inıcio de sua
implementacao.
No comeco, chamava-se CERN HTTP Server. Foi o primeiro servidor proxy a realizar
web cache. Em 1994, Wessels juntou-se ao projeto Harvest, que tinha por objetivo ser “um
conjunto integrado de ferramentas para reunir, extrair, organizar, pesquisar, fazer cache e re-
plicar informacoes da Internet“. Neste perıodo, o entao CERN teve tres grandes melhorias:
uso mais rapido do sistema de arquivos, uma arquitetura baseada em um unico processo e
hierarquia de cache usando o ICP (Internet Cache Protocol) [10]. Em 1995, o projeto Harvest
tornou-se comercial, ate 1996, em que Wessels, patrocinado pela NSF (National Science Fun-
dation) comecou a trabalhar no projeto IRCache, publicando o Harvest cache, com o nome de
Squid, sob a licenca GNU.
O projeto IRCache estendeu-se ate 2000. Desde entao, o projeto Squid e mantido
por uma comunidade de desenvolvedores voluntarios e mantido por doacoes e financiamentos
arbitrarios de empresas que usam ou se beneficiam de alguma forma com o Squid.
Hoje, o Squid e amplamente usado como uma alternativa eficaz para web caching,
gratuito. Vem no repositorio da grande maioria de distribuicoes Linux, como Ubuntu e Novell
SuSE Linux Enterprise Server.
Por ser uma ferramenta para controlar acesso a internet, que e considerado um re-
curso, ao Squid se aplicam os conceitos de protecao expostos na Secao 2.1.1. Desta forma,
vamos apresentar como o Squid faz esse controle de acesso pelo uso de um mecanismo de
23
autenticacao.
Quando um cliente solicita acesso a internet, o Squid o identifica por uma serie de
caracterısticas, algumas intrınsecas e outras que dependem da interacao do solicitante. De
forma geral, o controle de acesso poderia ser feito apenas por enderecos IPs, mas isso nao
e muito utilizado, porque exigiria um controle paralelo relacionando os usuarios com seus
respectivos enderecos IPs e que tambem todos seus enderecos IPs fossem fixos. Portanto, na
grande maioria das vezes, o controle e feito por nomes de usuario. Deste modo, a autenticacao
no Squid e feita da seguinte forma: o cliente (o navegador de internet, por exemplo) envia as
credenciais do usuario, que ele inseriu em uma janela de dialogo, em um campo chamado
Authentication no protocolo HTTP. Quando o Squid recebe o pacote, tenta decodificar o
conteudo deste campo e passa o conteudo decodificado a um programa que chamaremos de
auxiliar de autenticacao. Portanto, ao Squid compete o processo de autorizacao, enquando o
auxiliar de autenticacao e responsavel pelo processo de identificacao e autenticacao.
Neste contexto, o Squid suporta quatro metodos de autenticacao [8]:
1. Basic: e uma das formas mais usadas, entretanto uma das mais inseguras, pois o
conteudo do campo Authentication vem em formato Base-64, por isso, e facilmente
interceptado por um sniffer de pacotes. O metodo Basic da suporte a autenticacao sobre
um banco de dados, arquivos com padrao NCSA, NIS, LDAP, SMB, PAM, MSNT (contra
domınios Microsoft e Samba), SASL, POP3 e RADIUS.
2. Digest: e uma melhoria sobre o metodo Basic, em que as credenciais sao passadas com
encriptacao MD5. Suporta autenticacao sobre um arquivo texto e sistemas com suporte
a LDAP.
3. NTLM: e um protocolo de autenticacao proprietario desenvolvido pela Microsoft. Essen-
cialmente, o NTLM autentica um conexao TCP (e nao o usuario em si) e e um protocolo
binario, o que implica que apenas domınio Microsoft podem ser usados.
4. Negotiate: este e o metodo mais seguro desenvolvido. E um protocolo usado em am-
bientes que tem por autoridade de autenticacao o Microsoft Active Directory, e tambem
depende de versoes atualizadas de navegadores web, a saber, Internet Explorer, Mozilla
Firefox e Google Chrome. Neste metodo, as credenciais dos usuarios sao trocadas com
o Squid usando o protocolo Kerberos.
Para todas essas estrategias, ha um auxiliar de autenticacao associada. Neste traba-
lho, de maneira geral, estamos desenvolvendo um auxiliar de autenticacao, entretanto que nao
exija nenhuma interacao do usuario.
24
2.1.6 Comunicacao interprocessos
Em sistemas computacionais, os processos2 estao sempre se comunicando entre si
para que possam executar uma tarefa em comum.
Essa comunicacao pode acontecer em duas instancias [7]. Quando os processos
estao em execucao no mesmo sistema final, a comunicacao e feita usando metodos es-
pecıficos definidos pelo sistema operacional usado, por exemplo, piping, filas de mensagens
e memoria compartilhada. Processos em execucao em diferentes sistemas finais, por sua
vez, comunicam-se entre si trocando mensagens atraves da rede pela qual estao interligados,
atraves de mecanismos como soquetes, RMI (Remote Method Invocation) e RPC (Remote
Procedure Call).
Pela natureza desta proposta, vamos dar enfase a comunicacao em rede, usando so-
quetes, seus principais conceitos e caracterısticas de implementacao.
2.1.7 Aplicacao cliente-servidor: soquetes de rede
Uma aplicacao em rede consiste essencialmente em um par de processos que trocam
mensagens entre si. Como exemplo, podemos tomar um navegador Web e um site qualquer
da internet que, embora seja simples, contem todos os conceitos a serem abordados nessa
secao. A grosso modo, quando o usuario solicita acesso a um determinado site, o navega-
dor de internet envia uma mensagem ao servidor Web que hospeda o site, que por sua vez
responde com uma informacao padronizada de tal maneira que o navegador seja capaz de
entende-la e exibı-la.
A partir desse exemplo, podemos destacar dois pontos essenciais em qualquer aplicacao
distribuıda: um processo que inicia uma requisicao e outro que responde com uma informacao
organizada e padronizada. Ao processo que inicia a requisicao, da-se o nome de cliente. Ao
processo que responde, da-se o nome de servidor. A organizacao e padronizacao aplicada a
informacao enviada pelo servidor da-se o nome de protocolo.
Por isso, uma aplicacao em rede e dita aplicacao cliente-servidor. Todas as mensagens
trocadas entre uma aplicacao cliente-servidor sao organizadas segundo um protocolo, isto e,
um conjunto de regras que define o formato do conteudo da mensagem de tal maneira que ela
seja inteligıvel a ambas as partes envolvidas na troca de mensagens.2Processo e um programa em execucao, os recursos por ele alocados e todas as informacoes que estao sendo
manipuladas por ele.
25
Para enviar e receber mensagens, as aplicacoes cliente-servidor usam uma interface
de software chamada soquete. Os soquetes sao uma API entre a aplicacao e o meio de
transmissao, sao responsaveis por intermediar a comunicacao de dados entre o programa e
a rede. A Figura 5, adaptada de Kurose e Ross [7], ilustra muito bem o papel de um soquete
e como a aplicacao e o transporte se comunicam entre si. Por ser uma interface entre eles,
o soquete possibilita ao desenvolvedor um controle amplo sobre os elementos inerentes a
aplicacao, entretanto um controle mınimo no que diz respeito ao transporte: apenas a escolha
do protocolo e o ajuste de alguns de seus parametros.
FIGURA 5: Aplicacoes, soquetes e transporte.
Cada protocolo de transporte escolhido determina o tipo de soquete a ser utilizado.
Neste contexto, vamos abordar apenas soquetes TCP/IP, que compreende essencialmente
dois tipos: soquetes de fluxo, que usam o protocolo TCP, e soquetes de datagrama, que usam
o protocolo UDP (User Datagram Protocol). Como a aplicacao cliente-servidor desenvolvida
sera multiplataforma, isto e, o cliente sera executado em um sistema operacional (no caso,
Windows), enquanto o servidor sera executado em outro (no caso, Linux), duas linguagens
de programacao serao abordadas no ambito de implementacao de soquetes: C [11, 12] e
Java [13].
2.2 METODOLOGIA
Nesta secao, sera apresentada a metodologia de desenvolvimento do trabalho, desde
a apresentacao do problema, um esquema da solucao proposta, um detalhamentos das partes
da solucao e as ferramentas e ambiente computacional utilizados.
26
2.2.1 O problema
Neste trabalho, sera abordado o caso de autenticacao e autorizacao para acesso a
internet, o Novell eDirectory como base de usuarios, apresentado na Secao 2.1.4, e o Squid
proxy-cache como recurso em questao, apresentado na Secao 2.1.5.
Como discutido na Secao 2.1.1, a autenticacao e um fator importante e indispensavel
no uso de recursos em rede, para que se possa fazer sua protecao e tambem a auditoria de
uso. O controle de acesso a internet e um caso tıpico, e uma das finalidades de uso do Squid
e justamente proporcionar o controle de acesso e auditoria de uso da internet.
O primeiro problema diz respeito a usabilidade, dado que e necessario que o usuario
forneca suas credenciais sempre que precisar usar a internet, seja pelo navegador de internet,
seja por um programa de e-mail ou qualquer outro software que faca uso da internet por HTTP.
Isso acarreta problemas secundarios, como loops de autenticacao (quando o navegador, por
exemplo, comeca a pedir usuario e senha varias vezes) e programas que usem internet e nao
suportam mecanismos de passagem de usuario e senha. Um exemplo dessa solicitacao e
ilustrado na Figura 6, usando o navegador Mozilla Firefox. Essa janela aparece sempre que o
usuario abrir o navegador de internet.
FIGURA 6: Janela para autenticacao no navegador de internet.
Por outro lado, na Secao 2.1.5, discutimos a maneira que o Squid faz a autenticacao
dos clientes, e os metodos de autenticacao suportados. O metodo mais usado e o Basic,
entretanto nele encontramos o primeiro problema: as credenciais sao passadas ao servidor
de maneira insegura. Isso e extremamente preocupante, pois se estamos usando uma base
de usuarios unica. Para resolver esse problema temos apenas uma alternativa: usar o metodo
de autenticacao Digest. Ambas enviam as credenciais do usuario pelo protocolo HTTP usando
um campo chamado Authentication.
Neste contexto, a proposta deste trabalho e desenvolver um esquema de autenticacao
que extermine de uma vez por todas qualquer duvida de seguranca presente na transmissao
de credenciais pelo protocolo HTTP e eliminar o dialogo de solicitacao de credenciais apre-
27
sentados periodicamente por softwares que usam acesso a internet usando HTTP, como na-
vegadores de internet.
2.2.2 Ferramentas
Para o desenvolvimento do cliente SSO, utilizamos a linguagem C, a API da Novell para
comunicacao com o Novell Client, a API para threads da biblioteca windows.h e a biblioteca
para soquetes de rede winsock2.h. Para o desenvolvimento do servidor SSO, adotamos a lin-
guagem Java e a IDE de desenvolvimento Eclipse Helios (v3.6), munidos da API para soquetes
de rede da linguagem Java. Para a comunicacao entre o servidor e o Squid, estamos usando
a linguagem Perl, e para autenticacao web, a linguagem PHP e configuracoes de seguranca
usando certificados RSA.
Alem disso, as demais ferramentas sao:
• SuSE Linux Enterprise Server 10;
• Squid 2.5 stable 12;
• eDirectory 8.8 SP6;
• Apache 2.2.3.
2.2.3 Solucao proposta
Embora o proprio Squid ja possua um metodo de passagem de credenciais seguro (o
Digest, alem dos metodos para Microsoft, o NTLM e o Negotiate), a solucao proposta neste
trabalho procura contribuir para a usabilidade, usando uma estrategia de autenticacao SSO,
de forma que possa ser adaptada para qualquer infraestrutura de autenticacao que suporte
comunicacao por LDAP.
Primeiramente, vale observar em que se baseiam os metodos de controle de acesso
que o Squid possui. Quando uma requisicao de acesso e enviada, o Squid e capaz de controlar
o acesso baseado em varias caracterısticas dessa requisicao. As principais sao endereco IP
de origem e destino, domınio de origem e destino, endereco MAC de origem, porta de destino,
horario e, por fim, usuario solicitante. Esta ultima exige interacao do usuario, de forma que
forneca suas credenciais a serem validadas por um auxiliar de autenticacao do Squid (veja
Secao 2.1.5). A maneira mas comum e abstrata de fazer, portanto a mais usada, e baseada
em usuario solicitante. Daı surge a necessidade de uma estrategia de autenticacao.
28
Todavia, o objetivo deste trabalho e eliminar os dois problemas apresentados na secao
anterior, a saber:
• Interacao do usuario para fornecimento de credenciais;
• Envio de credenciais pelo protocolo HTTP.
Um problema complementa o outro. Analisando a situacao, se nao houver interacao do
usuario, nao havera envio de credenciais por HTTP. Por conseguinte, o objetivo consiste em
usar uma outra caracterıstica, presente na solicitacao do cliente sem sua interacao, para fazer
a autenticacao contra uma base de usuarios.
Diante disso, vamos usar o endereco IP do solicitante, por ser uma caracterısitica sa-
tisfatoria e que pode ser utilizada para varios fins. A proposta consiste no desenvolvimento
de uma aplicacao externa, que vamos chamar de Servidor SSO, responsavel por fazer a
associacao entre endereco IP e usuario autenticado. Com isso, o Squid nao implementaria
nenhum metodo de autenticacao, ao inves disso usaria um metodo externo que respondesse
como se fosse um auxiliar de autenticacao. Essa proposta e ilustrada na Figura 7.
FIGURA 7: Esquema geral da solucao proposta.
Assim, nao serao usados os metodos de autenticacao do Squid apresentados na
Secao 2.1.5, ao inves disso, o servidor SSO fornecera um nome de usuario mediante um
endereco IP, que sera usado pelo Squid para controle de acesso.
Do ponto de vista de usabilidade, a solucao proposta consiste em duas partes:
1. Uma aplicacao cliente para SSO: o servidor SSO sera uma aplicacao servidora, que se
comunicara com um cliente por soquetes de rede, a fim de implementar uma aplicacao
pseudo-SSO (veja Secao 2.1.3).
2. Uma interface segura para logon do usuario: sera uma interface web, usando HTTPS,
atraves da qual o usuario fornecera seu usuario e sua senha, isto e, fara o logon. Esse
logon possuira um TTL (Time to live): dentro deste perıodo, o usuario nao precisara for-
necer suas credenciais em nenhum momento, ao contrario do que acontece nos metodos
29
de autenticacao do Squid, em que o usuario precisa fornecer suas credenciais sempre
que um programa solicita acesso a internet.
Em vista da solucao proposta, podemos identificar entao algumas partes:
• O servidor SSO;
• Uma aplicacao cliente (para realizacao do SSO) que chamaremos de cliente SSO;
• Uma interface web para autenticacao segura no servidor SSO;
• Uma interface para comunicacao com o Squid (um auxiliar de autenticacao).
Essas partes e a estrategia de implementacao serao detalhadas nas proximas secoes.
2.2.3.1 O servidor SSO
O servidor SSO e uma aplicacao, feita em Java, com o objetivo de receber solicitacoes
do Squid contendo o endereco IP do solicitante e retornar o nome de usuario autenticado
naquele IP. Para obter essa informacao, o servidor SSO tera por base duas fontes:
1. O cliente SSO: baseado na estrategia de SSO, alguns clientes podem ter uma aplicacao
sendo executada em suas estacoes de trabalho. Essa aplicacao sera responsavel por
retornar ao servidor SSO o usuario autenticado nesta estacao. Vale ressaltar que nao
ha a necessidade do uso do cliente SSO para que o servidor SSO funcione, ele pode se
basear apenas no cache de usuarios, que sera apresentado a seguir.
2. Um cache de usuarios: O usuarios que nao tiverem o cliente SSO em suas estacoes
farao logon por uma interface web segura, usando credenciais de uma base LDAP con-
figurada, que sera responsavel por efetuar os processos de autenticacao e autorizacao.
Depois de devidamente autenticado, o servidor SSO armazena um cache em memoria e
em arquivos do usuario, seu respectivo endereco IP e a hora de seu logon, que servira
por base para um tempo util de vida de logon (o TTL). Isto funciona como se o usuario
estivesse se autenticando no servidor SSO.
Com isso, o servidor SSO e capaz de associar enderecos IPs com usuarios autentica-
dos. O cliente SSO e um modulo independente, que pode ser personalizado para funcionar
com qualquer infraestrutura de autenticacao. Neste trabalho, fizemos um estudo de caso para
funcionar em uma infraestrutura de autenticacao com Novell, baseado no sistema de diretorios
Novell eDirectory. Na Secao 2.2.3.2, sera detalhado melhor esse uso.
30
A Figura 8 contem o diagrama de classes do servidor SSO. A seguir, uma explicacao
mais minuciosa do que faz cada classe e qual sua importancia no funcionamento da aplicacao.
FIGURA 8: Diagrama de classes do Servidor SSO.
SquidComm
E a classe principal, e instanciada logo que a aplicacao e inicializada. Contem um loop
infinito, responsavel por ficar a escuta de solicitacoes do Squid. Na verdade, as solicitacoes
nao sao recebidas diretamente do Squid, mas de um script escrito em Perl que e usado como
auxiliar externo. Esse script sera apresentado adiante. As solicitacoes do Squid sao recebidas
com o uso de soquetes de rede, neste caso, e usado um soquete UDP na porta 3025.
RespThread
E uma classe privada da classe SquidComm. E uma implementacao da interface Run-
nable do Java para uso de threads. Ela e responsavel por processar as solicitacoes recebidas
na classe SquidComm. Usa threads para que haja concorrencia entre essas solicitacoes. E
nesta classe que e feita comunicacao com o cliente SSO e busca no cache de usuarios autenti-
cados pela interface web. Seu construtor recebe dois parametros, que representam o soquete
da solicitacao recebida do Squid na classe SquidComm.
E nesta classe que e feito o processamento principal da aplicacao e, por conseguinte,
e dado o retorno ao Squid. Esse retorno pode ser: (1) uma String contendo o nome do usuario
ou (2) uma String contendo a sequencia de caracteres ERR, que e a resposta que o Squid
31
espera caso nao seja encontrado nenhum usuario autenticado.
Esta classe contem uma regiao crıtica, isto e, uma parte do codigo que duas threads
nao podem usar ao mesmo tempo. No caso, o uso simultaneo causa o travamento de uma das
threads, e acontece quando o servidor SSO contata o cliente SSO: apenas um contato pode
ser feito por vez. Para solucionar esse problema, foi adotada a estrategia de exclusao mutua
usando semaforos. Esse e um semaforo estilo binario, isto e, ou a thread pode acessar ou
nao pode acessar. Ele e representado pelo atributo sem da classe ClientComm.
ClientComm
Esta classe e responsavel pela comunicacao com o cliente SSO, quando houver um.
Dado um certo endereco de IP, representado pelo parametro do metodo comunicaCliente,
essa classe tenta abrir um contato com esse endereco IP usando um soquete UDP na porta
3024. A resposta esperada e uma String contendo o nome de usuario autenticado na estacao
contatada. Caso o tempo limite de conexao expire (isto e, nao haja um cliente SSO sendo
executado no endereco IP dado), a classe retorna a String ERR.
CacheComm
A esta classe compete o processamento do cache de usuarios do servidor SSO. Este
cache consiste nos usuarios que se autenticaram no servidor SSO usando a interface web,
que sera apresentada adiante.
A representacao deste cache e feito de duas formas: na memoria volatil, ela e armaze-
nada como uma lista no servidor SSO (essa lista e o parametro ArrayList<Usuario> presente
em ambos os metodos da classe), e na memoria nao volatil, como arquivos com a seguinte
estrutura: o nome do arquivo e o endereco IP do cliente (no formato decimal) e o conteudo do
arquivo e o nome do usuario e o seu horario de logon. Neste contexto, existem dois diretorios
que armazenam esses arquivos: um chamado cache, que o servidor SSO processa em sua
inicializacao, e outro chamado queue, que sera processado durante a execucao do servidor
SSO. Os metodos processaCache e processaQueue processam o conteudo desses diretorios,
respectivamente, e armazenam na lista de usuarios.
32
IpConv
Essa classe e usada na conversao de enderecos IPs do formato de texto (represen-
tados por 4 octetos) para o formato decimal ou do formato decimal para o formato de texto.
Armazenar os enderecos IPs em formato numerico e nao em texto facilita a busca. A con-
versao e feita da seguinte forma:
1. Texto para Decimal: Feito pelo metodo IpToDec, dado um endereco IP ip = a.b.c.d no
formato texto, ele ira converter para o decimal dec da seguinte forma:
dec = a ∗ 224 + b ∗ 216 + c ∗ 28 + d
2. Decimal para Texto: E funcao do metodo DecToIP essa funcao, e a operacao inversa da
conversao anterior, pode ser modelada pelo seguinte algoritmo:
Dados o decimal dec, o endereco IP correspondente na forma ip = oct[1].oct[2].oct[3].oct[4]
pode ser obtido pelo algoritmo:
(a) Defina i = 1 e fator = 224;
(b) Faca oct[i] =
⌊dec
fator
⌋;
(c) Defina dec = dec− (fator ∗ oct[i]);
(d) Defina fator =fator
28, incremente i e volte para o Passo 2b se i ≤ 4.
Usuario
E a representacao do cliente. Possui apenas atributos, a saber: (1) nome – seu ID
de usuario, (2) ip – o endereco IP em que efetuou logon e (3) horaLogin – a hora em que o
usuario efetuou logon. Vale ressaltar que esta classe e usada apenas para representar a lista
de usuarios do cache, portanto nao e usada no SSO.
2.2.3.2 O cliente SSO
O cliente SSO e uma aplicacao cujo intuito e ser executada em clientes que estao
autenticados em alguma infraestrutura de autenticacao. Por isso o nome, pois e ele quem
fara o SSO para acesso a internet. Isto significa que o ID de usuario com o qual o cliente
se autenticou na infraestrutura de autenticacao existente sera reaproveitado para o acesso a
internet.
33
Deve ser uma aplicacao que permaneca em execucao e fique na escuta para receber
solicitacoes do servidor SSO.
Neste trabalho, abordamos a infraestrutura de autenticacao da Novell, usando o Novell
eDirectory. Um cliente se autentica na Novell usando um programa chamado Novell Client,
ilustrado na Figura 9. No ato do logon, o cliente SSO sera inicializado sem a intervencao do
usuario, por login script, um mecanismo que executa comandos no ato de logon do usuario.
FIGURA 9: Interface de logon do Novell Client.
Neste contexto, foi implementado um cliente SSO usando a linguagem C para sistemas
Windows, incorporando as APIs de threads e soquetes da Microsoft e as da Novell para lin-
guagem C. O cliente SSO e executado em segundo plano, e possıvel ver seu ıcone na bandeja
do Windows, como ilustrado na Figura 10. Quando recebe a solicitacao do servidor SSO, ele
retorna o ID de usuario da Novell que esta autenticado, realizando assim o SSO de quem esta
autenticado na infraestrutura da Novell.
FIGURA 10: Icone de bandeja do Cliente SSO.
Personalizacao do cliente SSO
Por ser uma aplicacao padrao, e por nao interessar ao servidor SSO qual a fonte de
usuarios que o cliente SSO esta consultando mas sim o ID do usuario propriamente validado,
o cliente SSO e uma aplicacao que pode ser personalizada e desenvolvida de acordo com a
infraestrutura de autenticacao da rede em questao.
O cliente SSO deve ser capaz de retornar o ID de usuario autenticado na estacao
34
em questao. Quando e iniciado, o cliente SSO deve ficar aguardando uma conexao na porta
3024 UDP. Quando o servidor iniciar o dialogo com uma saudacao, e o cliente deve enviar
o ID de usuario do cliente autenticado localmente, tambem pela porta 3024 UDP. Como a a
comunicacao nao e orientada por conexao, nao ha inıcio nem encerramento da conexao.
2.2.3.3 A interface web para logon do usuario
Esta interface web tem por objetivo minimizar a interacao com o usuario para que possa
se autenticar no servidor proxy quando o SSO nao estiver disponıvel. E uma aplicacao escrita
em PHP, que possuira apenas dois campos, para que o usuario possa inserir seu ID de usuario
e sua senha. A aplicacao entao faz o processo de identificacao e autenticacao do usuario
contra um servidor LDAP pre-configurado.
Quando o usuario efetua o logon, suas credenciais sao enviadas via HTTPS encrip-
tadas usando criptografia assimetrica com certificados RSA. Para consulta LDAP, o PHP faz
uma conexao segura usando LDAPS com a base de usuarios pre-configurada.
Se o processo de autenticacao for bem sucedido, a aplicacao gera um arquivo de cache
na pasta queue para que o servidor SSO possa processar o novo usuario autenticado (veja
Secao 2.2.3.1).
Essa aplicacao e composta por dois arquivos: a interface do usuario, e o index.php, e
a aplicacao PHP em si, chamada de verifica_senha.php. Este e o responsavel por efetuar o
processo de identificacao e autenticacao do usuario e redireciona-lo para a pagina desejada,
se for o caso. Portanto, e esta aplicacao que e responsavel por fazer validar as credenciais do
usuario e autentica-lo no servidor SSO.
2.2.3.4 A interface de comunicacao com o Squid
Esta interface serve como auxiliar de autenticacao para o Squid (veja Secao 2.1.5),
todavia serve aqui como um autenticador externo, isto e, nao se baseia em nenhum metodo
de autenticacao existente do Squid (Basic, Digest, NTLM e Negotiate). Seu principal objetivo e
encaminhar a solicitacao do Squid para o servidor SSO e retornar sua resposta para o Squid.
E um script escrito usando a linguagem Perl. Ele e inserido na configuracao do Squid
como uma aplicacao externa, assim e possıvel invocar essa aplicacao passando alguns
parametros suportados pelo Squid. Como discutido na Secao 2.2.3, o parametro escolhido
foi o endereco IP do solicitante. Neste contexto, a aplicacao envia o endereco IP recebido
do Squid para o servidor SSO, logo em seguida, recebe sua resposta, que pode ser o ID de
35
usuario autenticado no endereco dado ou a cadeia ERR, que significa que nao ha usuario au-
tenticado. Essa comunicacao e feita usando comunicacao nao orientada a conexao, isto e,
UDP, pela porta 3025.
Como o codigo deste script e mais curto, ele e apresentado no Apendice A. Nesta
versao do script, ele retorna ao Squid apenas qual usuario esta autenticado (no formato
OK user=ID) ou a cadeia ERR caso nao tenha encontrado ninguem autenticado no endereco
dado. Possıveis alteracoes neste script incluem manipulacoes com o usuario, como, por exem-
plo, contato com um servidor LDAP para verificar participacoes em grupo.
2.2.4 Preparacao do ambiente computacional
Nesta secao, o objetivo e descrever a maneira que todas as partes descritas ate aqui
interagem entre si e como sao configuradas. Todas as configuracoes, caminhos e versoes de
programas descritos aqui sao baseados em servidores SuSE Linux Enterprise Server 10 mas,
como todo Linux, pode ser facilmente adaptado para outras distribuicoes.
As configuracoes necessarias incluem:
• Configurar o Squid e o Servidor SSO;
• Configurar o Apache;
Algumas configuracoes que serao apresentadas nao sao obrigatorias, podem ser modi-
ficadas sem afetar o funcionamento do sistema. Todavia, o que e apresentado aqui foi testado
e esta em funcionamento. Vamos comecar pelas configuracoes necessarias no Squid.
2.2.4.1 Configurando o Squid e o Servidor SSO
O primeiro passo e adaptar a estrutura de diretorios do Squid para o funcionamento do
Servidor SSO.
A pasta dos arquivos de configuracao do Squid se encontram em /etc/squid. Neste
diretorio, sera criado um subdiretorio chamado sso, que contera:
1. O diretorio cache, onde ficarao os arquivos do cache do servidor SSO:
mkdir /etc/squid/sso/cache
2. O diretorio queue, onde ficarao os arquivos do cache do servidor SSO que ainda nao
foram processados:
mkdir /etc/squid/sso/queue
36
3. O diretorio htdocs, onde ficara a aplicacao web para autenticacao do usuario contra uma
base de diretorios LDAP:
mkdir /etc/squid/sso/htdocs
No diretorio /etc/squid/sso deve estar o arquivo de configuracao do servidor SSO,
nomeado sso.conf, que possui os seguintes campos, ja comentados:
cachePath = /etc/squid/sso/cache # caminho do cache
queuePath = /etc/squid/sso/queue # caminho da queue
logPath = /var/log/squid/sso # caminhos de logs
clientTimeout = 1000 # timeout de conex~ao com o cliente SSO
logonTTL = 21600 # time-to-live do logon pela web
sso = true # existencia do cliente SSO
Caso seja ocultado algum campo deste arquivo ou seu valor seja deixado em branco,
os valores padrao sao os apresentados neste exemplo, e serao assumidos pelo servidor SSO.
Depois, e importante verificar as permissoes de acesso dos diretorios recem criados.
Neste caso, como o servidor SSO sera executado pelo usuario root, nao teremos problemas
com os diretorios cache e queue, todavia o diretorio htdocs e acessado pelo usuario da dae-
mon do apache (em nosso caso, o usuario wwwrun pertencente ao grupo www), portanto e
necessario certificar-se que o diretorio possui ao menos permissao de leitura para outros ou
atribuir propriedade da pasta ao usuario wwwrun, da seguinte forma:
chwon -R wwwrun.www /etc/squid/sso/htdocs
Por fim, vamos criar um diretorio:
mkdir /etc/squid/sso/bin
que contera o executavel do servidor SSO. E um arquivo jar compilado pelo Eclipse. Para
rodar, basta entrar no terminal:
java -jar /etc/squid/sso/bin/sso.jar &
Isto conclui a instalacao do servidor SSO.
Agora, e necessario configurar o Squid para funcionar com o servidor SSO. O arquivo
de configuracao segue no Apendice B. Dele, vale destacar as clausulas:
1. external_acl_type SquidSSO ttl=0 %SRC /usr/sbin/squid_ip.pl
Esta clausula e responsavel por usar o auxiliar externo escrito em Perl, neste caso no
diretorio /usr/sbin, que e a interface de comunicacao entre Squid e servidor SSO apre-
sentada na Secao 2.2.3.4, criando uma acl interna do Squid chamada SquidSSO. A
37
variavel %SRC contem o endereco IP do solicitante e e passada para o script nesta cha-
mada.
2. acl autenticado external SquidSSO
Esta clausula cria uma regra de acesso do Squid simplesmente chamando a aplicacao
interna criada na clausula do Item 1.
3. http_access allow autenticado all
Esta clausula define que qualquer usuario que esteja autenticado conforme a aplicacao
externa definida no Item 1 tem permissao para acessar qualquer pagina HTTP. Na pratica,
o acesso e irrestrito, e apenas e sera registrado o nome de usuario retornado pelo auxiliar
externo.
4. deny_info ERR_TESTE all
Esta e uma clausula chave nesta configuracao. A clausula deny_info e chamada quando
o acesso e negado ao objeto especificado, neste caso, all, como definido na clausula do
Item 3. O primeiro parametro desta clausula define o que sera invocado quando o acesso
for negado. Neste caso, como ha simplesmente um nome, a pagina de erro exibida se
encontra em:
/usr/share/squid/errors/English/
e seu conteudo e simplesmente:
<meta
http-equiv="refresh"
content="0; url=https://<endereco_servidor>/ssologin/index.php?url=%U"
>
Isto significa que, sempre que o usuario obtiver um acesso negado, ele sera redirecio-
nado a pagina de logon da aplicacao web, apresentada na Secao 2.2.3.3. As questoes
de seguranca (repare que e chamado por https) e caminho da aplicacao serao discu-
tidos nas configuracoes do Apache. Merece destaque a variavel %U: ela contem a URL
solicitada pelo usuario, desta forma e possıvel redireciona-lo para sua pagina requisi-
tada caso sua autenticacao seja bem sucedida. Para mais variaveis disponıveis nesta
clausula, basta acessar a documentacao online do Squid [9].
2.2.4.2 Configurando o Apache
Tendo configurado o Squid, devemos configurar o Apache para:
38
1. Usar seguranca HTTPS;
2. Configurar o diretorio /etc/squid/sso/htdocs como diretorio de paginas valido.
Configurando a seguranca HTTPS
Para o funcionamento das configuracoes que serao apresentadas nesta secao, e indis-
pensavel que o modulo SSL do Apache esteja ativado. Para isso, basta entrar no terminal:
a2enmod ssl
Para configurar a seguranca, antes de tudo e necessario gerar e assinar os certifica-
dos. Usaremos o openssl, uma implementacao livre para gerar e assinar certificados RSA.
E importante lembrar que este metodo nao e recomendavel. Para grandes empresas e inte-
ressante que o certificado nao seja autoassinado, mas que seja assinado por uma autoridade
reconhecida, como a Verisign3 e a Thawte4.
Para gerar e assinar os certificados:
1. Primeiro, deve-se criar a chave privada:
openssl genrsa -out server.key 2048
2. Em seguida, deve-se gerar a requisicao de certificacao. Se fossemos usar uma autori-
dade de certificacao, como a Verisign, pararıamos aqui e enviarıamos o arquivo gerado
nesta etapa. Durante esse processo, sao solicitadas diversas informacoes, que devem
ser corretamente informadas, entretanto nao ha problema ao ignorar o pedido de senha
em challenge password:
openssl req -new -key server.key -out req.csr
3. Por ultimo, vamos assinar e gerar o certificado (este comando deve ser digitado em uma
unica linha). Este certificado sera valido por 10 anos:
openssl x509 -req -days 3650 -in req.csr -signkey server.key -out server.crt
Depois de gerados, a chave e o certificado devem ser copiados para os seguintes
diretorios, respectivamente:3Para mais informacoes, basta acessar http://www.verisign.com.br/.4Para mais informacoes, basta acessar http://www.thawte.com/.
39
cp server.key /etc/apache2/ssl.key
cp server.crt /etc/apache2/ssl.crt
Por fim, basta configurar o Apache. Para isso, basta criar um arquivo chamado:
/etc/apache2/vhosts.d/vhost-ssl.conf
O conteudo deste arquivo encontra-se no Apendice C. Depois de configurado, basta
reiniciar o servico do Apache e o acesso seguro por HTTPS estara disponıvel para qualquer
diretorio do servidor web.
Personalizando o caminho de diretorios de paginas do Apache
Agora, sera exposto como configurar o Apache para resolver o endereco:
https://<endereco_servidor>/ssologin
para o diretorio /etc/squid/sso/htdocs configurado na Secao 2.2.4.1 que contem a interface
web para logon do usuario.
Esta configuracao e feita usando um mecanismo do Apache chamado Alias. Para isso,
basta editar o arquivo /etc/apache2/default-server.conf e inserir:
Alias /ssologin "/etc/squid/sso/htdocs"
<Directory "/etc/squid/sso/htdocs">
Order allow,deny
Allow from all
AllowOverride All
</Directory>
Depois, e interessante que ainda que o solicitante tente acessar o endereco usando
HTTP seja automaticamente redirecionado para HTTPS. Isso pode ser feito usando o meca-
nismo Rewrite do Apache. E importante que o modulo de rewrite esteja ligado, usando-se o
comando:
a2enmod rewrite
Depois, basta inserir no arquivo /etc/apache2/default-server.conf as seguintes li-nhas:
<IfModule mod_rewrite.c>
RewriteEngine on
Rewritecond %{SERVER_PORT} ^80$
RewriteRule ^/ssologin/(.*) https://%{HTTP_HOST}/ssologin/$1 [NC,R,L]
</IfModule>
40
Depois de configurar esses mecanismos no Apache, quando o usuario acessar a URL:
http://<endereco_servidor>/ssologin
ele sera automaticamente redirecionado para o protocolo HTTPS e, se clicar nas informacoes
do certificado, podera ver o certificado gerado nesta secao como ilustrado na Figura 11.
FIGURA 11: Informacoes do certificado no navegador de internet.
2.2.4.3 Consideracoes desta implementacao
Essa implementacao envolve uma riqueza de configuracoes, embora seja da maneira
mais simples possıveis. De maneira geral:
1. A interface de comunicacao do Squid fica mais interessante se for alterada para que
manipule o ID de usuario recebido do servidor SSO e, a partir de outros parametros re-
cebidos do Squid, seja capaz de retornar outros resultados. Uma alteracao interessante,
por exemplo, seria alterar esse script para que, a partir do ID de usuario e de um nome
de grupo recebido do Squid, seja capaz de fazer uma consulta LDAP ao servidor de di-
retorios para verificar se ha participacao deste usuario no grupo. Com isso, o controle de
41
acesso seria mais centralizado, feito por grupos e nao por usuarios diretamente.
2. As configuracoes feitas no Apache foram esquematizadas para a distribuicao em questao,
o SuSE Linux Enterprise Server 10. Todavia, pode ser facilmente adapatada para ou-
tras distribuicoes, pois o Apache que roda naquela e a mesma que nestas. A principal
mudanca seria que todas as configuracoes feitas, sem excecoes, seriam realizadas di-
retamente em um arquivo chamado httpd.conf. E que no SuSE essa distribuicao de
arquivos e desenhada para organizar as configuracoes, todavia o Apache por padrao le
as configuracoes do arquivo httpd.conf, que esta em /etc/apache2/httpd.conf.
3. As configuracoes de seguranca por HTTPS garantem que as credenciais de logon do
usuario serao transmitidas usando criptografia assimetrica (RSA), portanto de maneira
segura.
2.3 RESULTADOS
A implementacao realizada apresentou bons resultados. O sistema SSO foi implemen-
tado de maneira bem sucedida, sendo que a aplicacao a infraestrutura de autenticacao da
Novell apresentou boas funcionalidades. Os resultados vieram como esperados.
Frente ao esquema de autenticacao proposto neste trabalho, temos duas instancias de
uso, descritas a seguir.
Com o uso de SSO
Isso acontece se houver uma infraestrutura de autenticacao presente e se houver um
cliente SSO implementado e sendo em clientes autenticados nessa infraestrutura. Em geral,
o fluxo de autenticacao e ilustrado no diagrama de sequencia da Figura 12.
42
FIGURA 12: Diagrama de sequencia para acesso a internet com SSO.
Sem o uso de SSO
Isso acontece quando o usuario faz logon no servidor SSO pela interface web, sem fa-
zer logon em uma infraestrutura de autenticacao diretamente. Neste caso, o fluxo de autenticacao
e ilustrado na Figura 13.
FIGURA 13: Diagrama de sequencia para acesso a internet sem SSO.
Neste contexto, e importante ressaltar que nem sempre e necessario que haja o logon
do usuario no servidor SSO. Este logon tem um tempo de vida, isto e, enquanto ele for valido,
o servidor SSO retorna o ID do usuario sem que este precise se autenticar novamente.
Por fim, cabe aqui analisar os resultados do ponto de vista dos problemas analisados.
Os problemas eram:
1. Interacao do usuario para fornecimento de credenciais
A solucao proposta foi bem sucedida na resolucao deste problema. No caso com SSO,
43
a interacao do usuario foi eliminada completamente, enquanto no caso sem SSO a
interacao foi minimizada ao maximo sendo que ha dependencia de interacao do usuario
apenas quando acessar a internet pela primeira vez e quando expirar o TTL de sua
autenticacao, definida pelo administrador na configuracao do servidor SSO (veja
Secao 2.2.4.1).
2. Envio de credenciais pelo protocolo HTTP
A solucao para esse problema tambem foi alcancada. No Apendice D, ilustramos captu-
ras feitas com o sniffer de rede Wireshark. E ilustrado o caso de autenticacao Basic do
Squid na Figura 14(a), em que as credenciais sao transmitidas sem nenhuma seguranca
por HTTP. Ja na Figura 14(b), e apresentado o caso de autenticacao depois do uso do
servidor SSO. Como o processo de autenticacao e troca de credenciais e toda feita entre
o servidor SSO e a autoridade de autenticacao (veja Figuras 12 e 13), no cliente nao
ha nenhuma transmissao de credenciais, a nao ser no momento da autenticacao pela
interface web, em que a transmissao e feita usando HTTPS.
44
3 CONCLUSOES
A implementacao atendeu aos requisitos iniciais, resolvendo os dois principais proble-
mas que foram tratados na Secao 2.2.1: o usuario nao precisa mais digitar a senha sempre
que abrir o navegador – nao precisa digitar a senha nunca se estiver autenticado na Novell –
e nao e mais possıvel capturar o usuario e senha do usuario, ja que nao e mais necessario o
metodo de autenticacao basico dos navegadores. Neste contexto, a aplicacao resolveu os pro-
blemas propostos e ate alguns que nao foram previstos. Por exemplo, aplicacoes que acessam
a internet mas nao sao preparadas para pedir usuario e senha (como um software chamado
Conectividade Social, da Caixa Economica Federal5) sao capazes de acessar a internet sem
problemas, visto que o pedido de autenticacao era o problema, e isto nao e mais necessario.
O trade-off conhecido entre seguranca e usabilidade em sistemas de autenticacao
SSO, como exposto na Secao 2.1.3, foi realmente constatado neste projeto. Sua aplicacao
num sistema proxy-cache foi adequado, visto que e imprescidıvel autenticacao neste caso.
O uso de soquetes de rede, expostos na Secao 2.1.7, tambem foi adequado: possibilitou a
distribuicao do sistema, isto e, permite que cada uma de suas partes estejam em maquinas
fısicas diferentes.
5Para mais detalhes, veja http://downloads.caixa.gov.br/_arquivos/fgts/conectividade_social/
Manual_Configuracao_CSE.pdf
45
Referencias
[1] De CLERCQ, J. “Single sign-on architectures”. In: DAVIDA, G.; FRANKEL, Y. & REES, O.Infrastructure Security, Lecture Notes in Computer Science. Springer Berlin / Heidel-berg, 2002. Vol. 2437, pp. 40-58.
[2] PASHALIDIS, A. & MITCHELL, C. “A taxonomy of single sign-on systems”. In: SAFAVI-NAINI, R. & SEBERRY, J. Information Security and Privacy, Lecture Notes in ComputerScience. Springer Berlin / Heidelberg, 2003. Vol. 2727, pp. 219-219.
[3] TODOROV, D. Mechanics of User Identification and Authorization: Fundamentals ofIdentity Management. Florida: Auerbach, 2007. 728 p.
[4] THE OPEN GROUP. Disponıvel em http://www.opengroup.org. Acesso em 18/11/2011.
[5] MACHADO, E.S. & MORI Jr., F.S. Autenticacao Integrada Baseada em Servico deDiretorio LDAP. 2006, 78 f. Trabalho de Conclusao de Curso – Ciencia da Computacao,Universidade de Sao Paulo, Sao Paulo, 2006.
[6] SHERESH, B. & SHERESH, D. Understanding Directory Services. 2. ed. Indianapolis:SAMS, 2002. 621 p.
[7] KUROSE, J.F & ROSS, K.W. Computer Networking: a top-down approach. 5. ed. NewYork: Addison-Wesley, 2010. 862 p.
[8] SAINI, K. Squid Proxy Server 3.1: Beginner’s Guide. Birmingham: Packt Publishing,2011. 308 p.
[9] SQUID ORG. Squid Documentation. Disponıvel em: http://www.squid-cache.org.Acesso em: 18/11/2011.
[10] WESSELS, D. Squid: the definitive guide. O’Reilly Media, 2004. 464 p.
[11] STEVENS, W. R.; FENNER, B.; RUDOFF, A.M. Programacao de rede UNIX: API parasoquetes de rede. 3. ed. Porto Alegre: Bookman, 2005. 901 p. ISBN 85-363-0470-7 (v. 1).
[12] DONAHOO, M.J.; CALVERT, K.L. TCP/IP Sockets in C: Pratical Guide for Programmers.2. ed. Burlington: Elsevier, 2009. 192 p.
[13] CALVERT, K.L.; DONAHOO, M.J. TCP/IP Sockets in Java: Pratical Guide for Program-mers. 2. ed. Burlington: Elsevier, 2008. 177 p.
46
Apendices
47
A Script Perl para comunicacao com o Squid
#!/usr/bin/perl
use IO::Socket::INET;
$SSOSERVER = ’192.168.56.1’;
$SSOPORT = 3025;
$| = 1;
while( <> ) {
$sock = new IO::Socket::INET->new( PeerAddr=>$SSOSERVER,
PeerPort=>$SSOPORT,
Proto=>’udp’ );
$sock->send( $_ );
$sock->recv( $resp, 1024 );
if( $resp eq "ERR" ) {
print "$resp\n";
}
else {
print "OK user=$resp\n";
}
close( $sock );
}
48
B Arquivo de configuracao do Squid
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
external_acl_type SquidSSO ttl=0 %SRC /usr/sbin/squid_ip.pl
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 172.20.1.0/24
acl autenticado external SquidSSO
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow autenticado all
deny_info ERR_TESTE all
http_access deny all
coredump_dir /var/cache/squid
49
C Arquivo de configuracao vhost-ssl.conf
<IfDefine SSL>
<IfDefine !NOSSL>
<VirtualHost _default_:443>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/srv/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /var/log/apache2/ssl_request_log ssl_combined
</VirtualHost>
</IfDefine>
</IfDefine>
50
D Capturas do Wireshark
(a) Captura do Wireshark para o caso de autenticacao Basic do Squid. Repare que as credenciais sao
transmitidas pelo protocolo HTTP, neste caso, de maneira insegura.
(b) Captura do Wireshark para o caso de autenticacao usando o servidor SSO. Nao ha transmissao de
credenciais, em nenhum dos casos, nem com ou sem o uso do cliente SSO.
FIGURA 14: Capturas do Wireshark.