JEDSON ZENDRON FIGUEIREDO
AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE
SISTEMAS INTEGRADOS A SERVIÇOS DE DIRETÓRIOS
Assis 2008
AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE
SISTEMAS INTEGRADOS A SERVIÇOS DE DIRETÓRIOS
JEDSON ZENDRON FIGUEIREDO
Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino Superior de Assis, como requisito do Curso de Graduação, analisado pela comissão examinadora:
Orientador: Douglas Sanches da Cunha
Analisador (1): Alex Sandro Romeo de Souza Poletto
Analisador (2): Domingos de Carvalho Villela Júnior
Assis 2008
JEDSON ZENDRON FIGUEIREDO
AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE
SISTEMAS INTEGRADOS A SERVIÇOS DE DIRETÓRIOS
Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino Superior de Assis, como requisito do Curso de Graduação, analisado pela comissão examinadora: Orientador: __________________________________________________________ Área de Concentração: ________________________________________________ ___________________________________________________________________ Assis 2008
DEDICATÓRIA
Dedico este trabalho a todos os professores que me ajudaram nessa batalha de graduação, em especial, para o meu orientador que desde o início do meu interesse pelo tema, me incentivou, mostrando caminhos a serem traçados para expor, ou mesmo, aplicar esse trabalho em investimentos futuros.
AGRADECIMENTOS
Agradeço principalmente, á Deus por abençoar nas horas de cansaço e pela empolgação e vontade de escrever.
Aos meus familiares, que constantemente me incentivaram e me ajudaram a dedicar ativamente aos estudos, mostrando-me a realidade da vida.
Em especial, ao meu pai pelo incentivo e determinação pelo meu sucesso. Pelo meu primo Osvandre Martins, na qual apresentou algumas formas de escrita e conteúdo do trabalho.
Ao professor, Douglas Sanches da Cunha, pela orientação e pelo constante estímulo transmitido durante o trabalho.
Aos amigos, Claudinei Moreira, Almir Rogério Camolesi, Alex Sandro Romeo de Souza Poletto e a todos que colaboraram direta ou indiretamente na execução deste trabalho.
RESUMO
As instituições de médio e grande porte demonstram dificuldade na manutenção das contas on-line de usuários, em virtude dos diferentes sistemas computacionais utilizados, de diferentes fornecedores. Promovendo, redundância nas informações e autenticações desencontradas. Com isso, uma das tecnologias de redes de computadores, pode auxiliar nessa circunstância, é o LDAP (Lightweight Directory Access Protocol). Conhecido como, um protocolo leve de acesso a diretórios, na qual tem por objetivo resolver os problemas de descentralização das informações do usuário, bem como, centralizar a autenticação. Favorece maior segurança nas informações de usuários, diminuição nos custos de implantação e gerenciamento, suportes para quaisquer recursos de redes acessarem serviços de diretórios. A partir disso, foi elaborado um aplicativo de manutenção dos usuários integrado a esses serviços do protocolo LDAP. E outro software, com dois algoritmos de teste, avaliando estatisticamente, conforme um cenário envolvendo outras tecnologias de rede, para testar o tempo (em segundos) da autenticação em até cem mil usuários.
ABSTRACT
The institutions of medium and large show difficulty keeping the accounts of users online, owing to different computer systems used in different suppliers. Promoting, redundancy in the information and endorsements missing. With this, one of the technologies of computer networks, can assist in that circumstance, is the LDAP (Lightweight Directory Access Protocol). Known as a lightweight protocol for access to directories, which aims to solve the problems of decentralization of user information, and to centralize authentication. It encourages greater security in the user's information, reduction in the cost of deployment and management, media resources for any network access services directories. From there, a new application for maintenance of the users of these services integrated with LDAP protocol. And other software with two algorithms for testing, evaluating statistically, as a scenario involving other network technologies, to test the time (in seconds) for authentication in up to one thousand thou and users.
LISTA DE ILUSTRAÇÕES
Figura 1 – História do LDAP ... 23
Figura 2 – Utilizando DIXIE para se comunicar com diretórios X.500 ... 24
Figura 3 – Modelo gateway LDAP/DAP ... 25
Figura 4 – Cliente do X.500 ... 26
Figura 5 – DAP (Directory Access Protocol) ... 26
Figura 6 – Pilha de Protocolos ... 27
Figura 7 – Arquitetura LDAP ... 28
Figura 8 – Representação de parte de um Diretório LDAP ... 29
Figura 9 – RDNs idênticos ... 30
Figura 10 – DN é uma seqüência de RDN’s ... 30
Figura 11 – Exemplo de entradas em um arquivo LDIF ... 32
Figura 12 – Classe de objeto person, retirada do core.schema... 33
Figura 13 – Recebimento de uma única entrada ... 35
Figura 14 – Recebimento de várias entrada ... 35
Figura 15 – Uma simples pesquisa no LDAP ... 36
Figura 16 – Estabelecimento de conexão, consultas e fechamento de uma conexão LDAP ... 37
Figura 17 – LDAP usando SASL com SSL/TLS ... 41
Figura 18 – Pontos de Falha da Replicação de Diretórios ... 43
Figura 19 – Redundância de Diretórios ... 43
Figura 20 – Ponto de Falha e Troca de Servidor ... 44
Figura 21 – Vários Clientes de Diretórios acessando somente um Servidor ... 45
Figura 22 – Vários Clientes de Diretórios acessando Servidores Replicados ... 45
Figura 23 – Detalhes da estrutura do diretório e tela de criação de novas entradas no diretório usando phpLDAPadmin ... 47
Figura 24 – Administração do diretório com LDAP Adm ... 48
Figura 25 – Edição avançada de atributos com o LDAP Admin ... 48
Figura 26 – Arquitetura da FEMA ... 51
Figura 27 – Estrutura de Diretórios da FEMA ... 52
Figura 28 – Variáveis que determinam a quantidade de Usuários de acordo com a Proporção ... 53
Figura 29 – Criação dos Usuários no Diretório LDAP, para cada Grupo, dependendo da proporção... 53 Figura 30 – Manutenção das Contas de Usuários ... 54 Figura 31 – Forma A e B de Autenticações de Usuários ... 55 Figura 32 – Resultados em Segundos de duas formas de Autenticações de Usuários para quatro tipo de conexões a Internet com três quantidades de Usuários ... 57 Figura 33 – Integração dos Usuários de Sistemas ao Serviço de Diretórios
OpenLDAP... 59 Figura 34 – Caso de Uso do Modelo de Negócio ... 61 Figura 35 – Diagrama de Classes Beans e LDAP ... 62 Figura 36 – Página de Autenticações dos Usuário para efetuar o acesso ao
Aplicativo Demonstrativo ... 63 Figura 37 – Aplicativo Demonstrativo ... 64 Figura 38 – Permissões de Ação do Usuário Simples que acessou ao Aplicativo Demonstrativo ... 65 Figura 39 – Algoritmo que Insere os Usuários no diretório LDAP, de acordo com a Proporção ... 70 Figura 40 – Algoritmo que Autenticar os Usuários, a partir de somente uma abertura e um fechamento da conexão com o LDAP (Avaliação A), de acordo com a
Proporção ... 71 Figura 41 – Algoritmo que Autenticar os Usuários, a partir da abertura e fechamento da conexão com o LDAP para cada validação (Avaliação B), de acordo com a
Proporção ... 72 Figura 42 – Algoritmo que Apaga todos os Usuários do diretório LDAP, de acordo com a Proporção ... 73 Figura 43 – Avaliação A da Autenticação de Mil Usuários com Conexão de Internet Dial Up ... 74 Figura 44 – Avaliação A da Autenticação de Mil Usuários com Conexão de Internet Rede Local... 75 Figura 45 – Avaliação A da Autenticação de Cem Mil Usuários com Conexão de Internet Wireless ... 76 Figura 46 – Avaliação B da Autenticação de Dez Mil Usuários com Conexão de Internet Rede Local ... 77 Figura 47 – Autenticação de Usuário ... 78
Figura 48 – Manutenção de Dados dos Usuários ... 78
Figura 49 – Movimentação das Permissões de Ação dos Usuários ... 79
Figura 50 – Relatório das Permissões de Ação aos Grupos e Usuários ... 79
Figura 51 – Autenticação do Usuário no Diretório LDAP ... 80
LISTA DE TABELAS
Tabela 1 – Alguns exemplos de Object Identifie ... 31 Tabela 2 – Algumas abreviaturas de atributos, com seus respectivos nomes... 32 Tabela 3 – Resultados do Tempo de Autenticações de Usuários ... 56
LISTA DE ABREVIATURAS E SIGLAS
SGBD Sistema de Gerenciamento de Base de Dados
DNS Domain Name System
DIT Directory Information Tree
RFC Request For Comments
LDAP Lightweight Directory Access Protocol LDAPv1 LDAP primeira versão
LDAPv2 LDAP segunda versão LDAPv3 LDAP terceira versão Kerberos v4 Kerberos quarta versão Kerberos v5 Kerberos quinta versão
TCP/IP Transmition Control Protocol / Internet Protocol IETF Internet Engineering Task Force
OSI-DS Open Service Interface Definitions SMTP Simple Mail Transfer Protocol HTTP Hypertext Transfer Protocol FTP File Transfer Protocol
TELNET Tipos de Acesso na Internet
ISO International Standardization Organization
CCITT Consultative Committee for International Telegraphy and Telephony DAP Directory Access Protocol
OSI Open System Interconnection DAS Directory Assistance Service
DIXIE Directory Interface to X.500 Implemented Efficiently LDBP Lightweight Directory Browsing Protocol
DSML Directory Services Markup Language SPML Service Provisioning Markup Language SLP Service Location Protocol
SASL Simple Authentication Security Layer
DIGEST-MD5 Using Digest Authentication as a SASL Mechanism StartTLS Extension for Transport Layer Security
TLS Transport Layer Security SSL Secure Sockets Layer
SSO Single Sing On
DN Distinguished Name
CN Common Name
RDN Relative Distinguished Name LDIF LDAP Data Interchange Format OID Object Identifier
IANA Internet Assigned Number Authority
SN Surname
GN Given Name
O Organization Name
OU Organization Unit Name
ST State or Province Name
L Locality Name
C Country
DC Domain Component
UID User Identification
MSGID Identificador de mensagens
IP Internet Protocol
PAM Pluggable Authentication Modules
NSS Name Service Switch
POSIX Portable Operating System Interface
FEMA Fundação Educacional do Município de Assis
IDE Intelligent Drive Electronics ou também Integrated Drive Electronics
JSP Java Server Pages
JNDI Java Naming and Directory Interface JEE Java Enterprise Edition
JMS Java Message Service
API Application Programming Interface SPI Service Provider Interface
IEEE Institute of Electrical and Electronics Engineers ADSL Asymmetric Digital Subscriber Line
AJAX Asynchronous Javascript And XML XML Extensible Markup Language MVC Model View Controller
UML Unified Modeling Language
SUMÁRIO
1 INTRODUÇÃO ... 17
1.1 JUSTIFICATIVA E MOTIVAÇÕES
...17
1.2 OBJETIVOS ... 18
1.3 ESTRUTURA DO TRABALHO ... 19
2 CONCEITOS DE SERVIÇOS DE DIRETÓRIOS ... 21
2.1 O QUE É UM SERVIÇO DE DIRETÓRIO? ... 21
2.2 O QUE É LDAP? ... 22
2.3 HISTÓRIA DO LDAP ... 22
2.4 ORIGEM DO LDAP ... 25
2.4.1 Diretório X.500 ... 25 2.4.2 Cliente do X.500 ... 26 2.4.3 DAP ... 26 2.4.4 Pilhas de protocolos ... 26 2.4.5 Versões ... 272.5 POR QUE USAR LDAP? ... 28
2.6 DIRETÓRIO LDAP ... 29
2.7 SCHEMA ... 29
2.8 DISTINGUISHED NAMES (DN) ... 30
2.9 O QUE É LDIF? ... 30
2.10 OBJECT IDENTIFIER (OID) ... 31
2.11 ATRIBUTO ... 31
2.12 ENTRADA ... 32
3 PROTOCOLO LDAP ... 34
3.1 OPERAÇÕES ... 34
3.2 SEGURANÇA ... 37
3.2.1 Métodos de Autenticação ... 38
3.2.2 Métodos de Criptografia ... 40
3.2.3 Modelo de Controle de Acesso ... 41
3.3 OTIMIZAÇÕES DO LDAP ... 42
3.3.1 Replicação do serviço de diretórios ... 42
3.3.2 Diretórios distribuídos ... 44
3.4 OPENLDAP ... 46
3.5 FERRAMENTAS PARA GERENCIAR UM SERVIDOR LDAP ... 46
4 ARQUITETURA DE DIRETÓRIOS ... 50
4.1 CONSIDERAÇÕES ... 50
4.2 AVALIAÇÃO DA AUTENTICAÇÃO DE USUÁRIOS ... 52
4.3 ESTATÍSTICA DA ESTRUTURA DE DIRETÓRIOS DA FEMA ... 56
5 APLICATIVO DEMONSTRATIVO ... 58
5.1 CONSIDERAÇÕES ... 59
5.2 MODELAGEM E APRESENTAÇÃO DO APLICATIVO ... 60
6 CONCLUSÕES ... 66
REFERÊNCIAS BIBLIOGRÁFICAS ... 68
ANEXO A – ALGORÍTMOS DA AVALIAÇÃO DA AUTENTICAÇÃO .. 70
ANEXO B – RESULTADOS DOS TESTES DAS AUTENTICAÇÕES .. 74
ANEXO C – DIAGRAMAS DE CASO DE USO – CAPÍTULO 5 ... 78
1 INTRODUÇÃO
A evolução tecnológica nas redes de computadores se tornou estratégica para as mais diversas organizações. Com essa realidade, é fundamental a criação de métodos de aplicação e estudos voltados para garantir a segurança das informações.
As empresas estão cada vez mais informatizando seus processos e nem sempre é possível ter um único sistema que atenda a todas as necessidades, principalmente se estes não forem desenvolvidos internamente, mas sim, adquiridos ou contratados de fornecedores. Diante disso, é comum encontrar organizações que usam vários sistemas diferentes, oriundos de fornecedores diferentes nos quais cada um possui recursos específicos de controle de acesso (LUPPI, 2008).
O referido fato geralmente resulta num oneroso trabalho de administração de contas de usuário e senhas. As instituições nem sempre possuem uma boa administração na segurança das informações, devido à existência de poucos recursos para gerenciá-las, na qual acarreta problemas, que conseqüentemente oferecem várias oportunidades para ataques de hackers, crackers e outros tipos de invasões.
1.1
JUSTIFICATIVAS E MOTIVAÇÕES
As aplicações de uma instituição, localizadas em diferentes servidores, têm desvantagens quando se pretende aproveitar as informações dos usuários, devido às autenticações serem em bancos de dados e tabelas diferentes. Com isso, as manutenções das contas tornam-se complexas, por causa da ambigüidade das informações, visto que, para cada aplicativo serão necessárias as mesmas credenciais.
No entanto, pode-se criar uma hierarquia em árvore que denomina uma estrutura do ponto de vista lógico que se distribui fisicamente em repositórios de diferentes servidores de diretórios, a fim de dividir os tipos de usuários por um único domínio (Organização).
A relevância do problema e a existência de tecnologias que se propõem a auxiliar e resolvê-los, constituem na principal motivação para a realização deste trabalho. Uma
dessas tecnologias é o protocolo de rede chamado LDAP (Lightweight Directory Access Protocol), conhecido como sendo protocolo leve de acesso a diretórios, que se propõe resolver o problema da descentralização de informações de usuários, dos vários sistemas das instituições de médio e grande porte, proporcionando agilidade e redução de custo (MALDANER, 2004).
Segundo MALDANER (2004), o uso do LDAP pode trazer mais agilidade em vários sistemas de empresas: “A pessoa não precisa lembrar de todas as senhas, basta apenas lembrar da sua senha para abrir todos os sistemas da empresa e as demais senhas são armazenadas no diretório LDAP".
A idéia da centralização das informações dos usuários facilitará os acessos aos vários sistemas e recursos da rede, a partir de uma única identificação coletada após a autenticação do usuário no diretório LDAP.
1.2
OBJETIVOS
A proposta de uma alternativa (Open Source e Freeware) para a implementação das funcionalidades de autenticações aplicáveis a sistema de software.
Fundamentar e avaliar a autenticação de usuários, a partir da criação de dois algoritmos específicos, nas quais um deles executará, seqüencialmente (em clientes Windows ou Linux), uma rotina de autenticações com somente uma abertura e fechamento da conexão com o serviço de diretórios, já outro algoritmo, após cada autenticação. Essa avaliação coletará, estatisticamente, informações com o intuito de integrar os usuários de sistemas aos diretórios LDAP. Para a realização dos cálculos de autenticação em até cem mil usuários, será necessária a implementação de outro algoritmo para a criação automática das contas.
A elaboração de um aplicativo demonstrativo que realizará a manutenção das contas de usuários no diretório LDAP, porém, integrada com as permissões de acessos há sistemas on-line, que conseqüentemente, após uma única autenticação, disponibilizará as credenciais válidas (retornadas pelo serviço de diretórios), na qual será a chave de acesso às informações do usuário de sistemas e também a possibilidade de efetuar a mesma autenticação a quaisquer recursos de rede.
Agregar conhecimentos sobre os conceitos, tecnologias, métodos e técnicas de autenticação dos usuários baseada em serviços de diretórios.
1.3
ESTRUTURA DO TRABALHO
Esse trabalho foi organizado em seis capítulos, da seguinte forma: o Capítulo 1 apresenta o esboço do que será apresentado, os interesses pela pesquisa, juntamente com a idéia de centralização das contas de usuários com a criação de uma árvore de diretórios. No Capítulo 2 explica-se alguns conceitos de serviços de diretórios, o significado de LDAP, a história delimitando o protocolo que originou, a forma que o mesmo se comunicava com o diretório X.500, a apresentação da pilha de protocolos com a demonstração do local em que o LDAP atua, as versões, a importância de se usar essa tecnologia, a apresentação da arquitetura, como também todas as diretrizes que são utilizadas.
O Capítulo 3 descreve o protocolo LDAP, visto que opera quatro modelos básicos com operações baseadas na comunicação entre cliente e servidor. Os aspectos fundamentais para a segurança das informações, com a utilização de métodos de autenticação e criptografia, bem como, o modelo de controle de acesso na qual, restringe o tipo de acesso dos usuários e grupos. A otimização do LDAP a partir da replicação e distribuição de diretórios, averiguando os pontos de falha e as maneiras eficientes para a utilização do serviço de diretórios. O relato do padrão de código aberto chamado OpenLDAP, na qual, traz este protocolo ao alcance dos usuários Linux, ou mesmo, do desenvolvimento de sistemas para aplicações LDAP. E as ferramentas que gerenciam as contas dos usuários contidas nos diretórios.
Após a apresentação de todo o conceito da tecnologia LDAP, no Capítulo 4 será apresentado à depuração de todos os resultados da autenticação dos usuários, a fim de calcular o tempo, em segundos, de identificação no diretório LDAP, aplicando uma estatística para a análise de performance a fim de averiguar a possibilidade de integração dos usuários de sistemas ao serviço de diretório.
Já no Capítulo 5, a criação de um aplicativo em Java para Web, que fará a manutenção as contas dos usuários de sistemas, incluindo os mesmos no diretório LDAP e atribuindo permissões de acesso há sistemas de software.
E por fim, as considerações finais, demonstrando os resultados da pesquisa, vantagens e desvantagens, ou mesmo, a contribuição com outros pesquisadores.
2 CONCEITOS DE SERVIÇO DE DIRETÓRIOS
O serviço de diretórios relaciona-se a um conjunto de funções para criação, armazenamento e recuperação de informações de um diretório.
Esse serviço, por muitos motivos, é um componente vital para o gerenciamento integrado de identidades, o principal deles é a constituição da forma mais comum para armazenamento e disponibilização das informações para os diversos sistemas operacionais de rede (REINHART et. al., 2005).
2.1
O QUE É UM SERVIÇO DE DIRETÓRIOS?
O serviço de diretórios, de uma forma simples, é uma base de dados em que podem ser armazenadas informações de usuários, na qual poderão ser recuperadas a qualquer momento, assim como em SGBD (Sistema de Gerenciamento de Base de Dados) convencional (Mysql, Postgresql, Oracle, Microsoft SQL Server e etc) (SUNGAILA, 2007).
Os diretórios disponibilizam prontamente os dados solicitados com alta otimização de leitura, a qual se cria uma estrutura em formato hierárquico de árvore (semelhante ao modelo DNS – Domain Name System), de modo que dentro de cada registro será armazenado um ramo específico da árvore. Para isso, foi criado um padrão de diretórios globais, chamado DIT (Directory Information Tree), ou seja, árvore de diretório que acessa as informações contidas nos diretórios de forma hierárquica.
Com base numa empresa (raiz da DIT), podem ser criadas estruturas independentes para cada departamento ou unidade (ramos da DIT). Tais informações apresentarão um modelo distribuído para armazenamento em servidores diferentes.
Todos os dados armazenados em um diretório seguem uma forte padronização, normalmente estabelecida em RFC (Request For Comments), ou mesmo, pedido de comentários, contendo nomenclatura específica e tipos de dados de forma consistente.
Optar pelo uso de um diretório, em alguns casos, torna-se uma tarefa difícil. Com isso, para afirmar que uma base de dados terá desempenho mais adequado do que um diretório para aplicação específica, envolve a análise de vários pontos, visto que o SGBD contém estruturas muito similares à servidores de diretórios e compartilham muitas características como pesquisa rápida e base de dados com fácil personalização.
O volume de escrita dos servidores de diretórios geralmente não possui métodos avançados que controle as transações ou esquemas de roll-back (comando que desfaz a transação corrente, fazendo com que todas as modificações realizadas pela transação sejam rejeitas). Isso ocasiona um baixo desempenho na escrita, na qual está seu ponto fraco. Pois têm como base, que as informações dificilmente serão alteradas.
A hierarquia denomina uma estrutura em forma de árvore do ponto de vista lógico que distribui fisicamente em repositórios de diferentes servidores de diretórios, que podem ser agrupados por departamentos, ou mesmo, por unidades geograficamente distantes.
A descentralização possibilita a administração de parte do diretório (unidades ou ramos) a outros usuários, sendo que os “ramos” podem estar localizados fisicamente em outros servidores (SUNGAILA, 2007).
2.2
O QUE É LDAP?
O LDAP é um protocolo leve de acesso a diretórios que atua na camada de aplicação da pilha de protocolos TCP/IP (Transmition Control Protocol / Internet Protocol), nos padrões IETF (Internet Engineering Task Force) e OSI-DS (Open Service Interface Definitions), como por exemplo, o SMTP (Simple Mail Transfer Protocol), HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), TELNET (Tipos de Acesso na Internet) e tantos outros (BRESSAN, 2007).
2.3
HISTÓRIA DO LDAP
No início da década de 80, as duas instituições ISO (International Standardization Organization) e CCITT (Consultative Committee for International Telegraphy and
Telephony), se uniram para desenvolver um serviço de mensagem. Entretanto, houve necessidade em organizarem entradas num serviço de nomes de forma hierárquica, que tivesse grande capacidade de armazenamento e pesquisa da informação. Esse trabalho foi concluído no final da década de 80, recebendo o nome de X.500, o qual especificava que a comunicação entre o cliente e o servidor de diretório deveria utilizar o protocolo DAP (Directory Access Protocol), baseado no modelo OSI (Open System Interconnection) (Figura 1) (BARTH, SIEWERT, 2006).
Figura 1. História do LDAP, estimada por (PAPOTTI et. al., 2006)
O DAP é um protocolo pesado, que roda sobre uma camada OSI completa, e precisa de uma quantidade significante de recursos computacionais para ser executado. Tendo isso em vista, pensou-se em criar um protocolo mais leve para que também fosse utilizado em máquinas de menor poder computacional, em desktops convencionais. Então foram desenvolvidos dois protocolos, o DAS (Directory Assistance Service) e o DIXIE (Directory Interface to X.500 Implemented Efficiently), que foram os predecessores do LDAP, mas que ainda eram muito ligados ao X.500, já que precisavam de um servidor intermediário para efetuar a “tradução” desses protocolos para o DAP, que se comunicaria com o diretório X.500 (Figura 2).
Figura 2. Utilizando DIXIE para se comunicar com diretórios X.500, estimada por (PAPOTTI et. al., 2006)
O protocolo LDAP foi desenvolvido originalmente por três pesquisadores em 1993, na universidade de Michigan, chamados Steve Killi, Tim Howes e Wengyik Yeong. De acordo com o que foi comentado anteriormente, o LDAP funciona sobre o padrão de diretórios X.500 melhorado, na qual foi uma tentativa bem sucedida de ser um protocolo compatível com o DAP, que deu origem ao LDAP, proporcionando um custo menor, além de utilizar pouco poder computacional. As razões da melhoria de desempenho devem-se ao fato do LDAP não fazer uso do protocolo OSI, mas construiu conexões diretas do cliente com o servidor de diretórios (SEZANOWITCH, 2006).
Devido a desenvolvimento do protocolo X.500, ter sido baseado no modelo OSI de sete camadas de implementação de redes, determinou-se uma quantidade enorme de informações e controles. Com isso, a implementação mostrava-se impraticável, por que não conseguia ser utilizada com o modelo TCP/IP largamente adotado nas redes de computadores. Por esse motivo, esse conjunto de regras, deu origem a uma implementação mais simples, o LDAP.
O LDAP, inicialmente, era chamado de LDBP (Lightweight Directory Browsing Protocol), no qual os acessos aos servidores de diretórios só permitiam a leitura de dados. Com a evolução tecnológica, o LDBP além de passar a escrever e editar os diretórios, ele manteve-se autonomamente, como um servidor que foi nomeado
como LDAP, tornando uma alternativa independente do DAP, que ainda era mantido compatível e paralelamente ao serviço de diretórios (SEZANOWITCH, 2006).
2.4
ORIGEM DO LDAP
Esse protocolo originou-se como um meio de acesso a diretórios do tipo X.500, a partir do serviço de diretório OSI. Inicialmente, os clientes LDAP acessavam gateways para esse tipo de serviço. Esses gateways (também chamados de proxy ou front-end) rodavam o LDAP entre o cliente e o gateway, já o DAP entre gateway e o servidor X.500 (Figura 3) (MACHADO; MORIJR, 2006).
Figura 3. Modelo gateway LDAP/DAP, estimada por (MACHADO; MORIJR, 2006) A partir daí, como foi citado anteriormente, o LDAP não precisa rodar na pilha de sete camadas OSI, como o protocolo de camada de aplicação X.500. Os pacotes X.500 carregam mais bagagem, pois precisam de cabeçalho para cada uma das camadas da pilha de protocolos OSI. A suíte de protocolos TCP/IP, na qual o LDAP roda, também necessita de cabeçalho nos pacotes, mas tem um overhear (escutar algo sem que os outros saibam, ouvir por acaso) menor (MACHADO; MORIJR, 2006).
2.4.1 Diretório X.500
O diretório X.500 caracteriza-se em conexões de serviços de diretórios locais, a fim de formar um diretório global distribuído, parte do diretório fica global e suas informações são disponibilizadas através de um agente do sistema de diretórios e trabalha com funções de gerenciamento, isto é, adição, modificação e deleção de entradas (PAPOTTI et. al., 2006).
2.4.2 Cliente do X.500
O LDAP foi desenvolvido para ser um cliente para o X.500 (Serviço de Diretório OSI), que define o DAP para os clientes usarem quando estiverem em contato com servidores de diretório (Figura 3) (PAPOTTI et. al., 2006).
Figura 4. Cliente do X.500, estimada por (PAPOTTI et. al., 2006) 2.4.3 DAP
Comentado anteriormente, o DAP era um protocolo de acesso a diretórios, da camada de aplicação, difícil de trabalhar e implementar, visto que os protocolos mais fáceis foram desenvolvidos com a maior parte de sua funcionalidade, mas com menor complexidade (Figura 5) (PAPOTTI et. al., 2006).
Figura 5. DAP (Directory Access Protocol), adaptada por (PAPOTTI et. al., 2006) 2.4.4 Pilha de Protocolos
No modelo de referência OSI, os dados descem a pilha de protocolos para chegar à rede e sobem para chegar às aplicações. Cada camada da pilha de protocolos adiciona um cabeçalho com informações de controle e trata o que recebe da camada superior com dados. Esta adição de informações de controle em cada nível é denominada encapsulamento. No entanto, sendo o DAP um protocolo da camada
de aplicação, usá-lo implicava suportar toda a pilha de protolocos desse modelo (Figura 6) (LEITE, 2008).
A Internet (que entretanto adotava definitivamente o TCP/IP), não estava preocupada, pois não queria perder o mercado dos computatores menos poderosos, com recursos insuficientes para suportar o modelo OSI. Com isso, o protocolo LDAP atua diretamente sobre o TCP/IP, porém não requer hardware pesado para operações (LEITE, 2008).
Figura 6. Pilha de Protocolos, estimada por (LEITE, 2008)
2.4.5 Versões
O LDAP influenciou protocolos de Internet subseqüentes, incluindo versões posteriores do X.500, DSML (Directory Services Markup Language), SPML (Service Provisioning Markup Language) e o SLP (Service Location Protocol).
A primeira versão foi publicada como a RFC 1487 em 1993, mas o LDAP ganhou uso somente em 1996, na segunda versão (LDAP v2), especificada na RFC 1777, na qual, existiam autenticações fortes com o Kerberos v4 e v5.
Em 1997, publicou-se a terceira e última versão, na RFC 3377, que foi desenvolvida para solucionar uma série de limitações existentes na anterior, a qual inclui aspectos de segurança, que passa a suportar protocolos de autenticação forte, como o SASL (Simple Authentication Security Layer) e o SSL (Secure Sockets Layer) / TLS (Transport Layer Security) (Figura 1) (PAPOTTI et. al., 2006).
2.5
POR QUE USAR LDAP?
O LDAP é otimizado para fazer pesquisas de informações, na qual centralizam todas elas a fim de disponibilizar enormes benefícios, tais como um único ponto de administração, como também, reduz os dados duplicados. Possui mecanismos de replicação incluída (slurpd) e de segurança tanto para autenticação (SASL) como para a troca de dados (SSL/TLS) (CARTER, 2003).
Porém, em alguns casos não substitui as bases de dados relacionais, raramente são efetuadas atualizações, apenas convém guardar os dados estáticos. Obviamente não é possível relacionar dois atributos, visto que não se trata de uma base de dados relacional, mas sim de uma base de dados estruturada hierarquicamente. Exemplo: “Não é possível relacionar o código de uma disciplina com o nome da mesma” (CARTER, 2003).
Em algumas aplicações que o LDAP exerce, se conscientiza em SSO (Single Sing On), ou seja, autenticação única que facilita a integração com outros serviços, como por exemplo, servidor de arquivos, de proxy, de domínio, de impressão, de e-mail, entre outros. Sendo assim, o usuário tem apenas um “uid” (identificador do usuário) (Figura 8), e uma senha para acessar os diversos recursos da rede e não mais para cada serviço que queria utilizar (Figura 7).
2.6
DIRETÓRIO LDAP
O modelo de serviço do diretório LDAP é baseado em entradas. Uma entrada é um conjunto de atributos e é referenciada através de um nome distinto – DN (Distinguished Name). Porém, é usado para referenciar uma entrada de forma não ambígua. Cada um dos atributos de entrada tem um tipo, e um ou mais valores chamados de objetos. Estes tipos geralmente são palavras mnemônicas, como CN (common name). (Figura 8) (KELLERMANN, SILVELLO, 2001).
Figura 8. Representação de parte de um Diretório LDAP
2.7
SCHEMA
Os schemas permitem manter a consistência dos dados de um diretório, é extensível, ou seja, trabalham com a herança e permitem adicionar mais atributos e classes de acordo com as necessidades. Porém, eles definem a classe de objeto, os atributos e seus possíveis valores, que podem ser inseridos em um diretório (SUNGAILA, 2007).
Se uma entrada, que é tratada como um objeto, não obedecer às regras do schema, este não poderá ser inserido.
2.8
DISTINGUISHED NAMES (DN)
O DN é utilizado para identificar e diferenciar uma entrada para não gerar informações repetidas em um serviço de diretórios, ou seja, esta entrada vai ser única e não haverá outra entrada com o mesmo nome. São compostos por uma seqüência de RDN (Relative Distinguished Name), sendo que, cada seqüência é um ramo da DIT, desde a raiz até o objeto ao qual o DN faz referência (Figura 9) (PAPOTTI et. al., 2006).
Figura 9. RDNs idênticos
Um DN é formado por uma seqüência de RDN’s separados por vírgulas (Figura 10).
Figura 10. DN é uma seqüência de RDN’s
2.9
O QUE É LDIF?
O LDIF (LDAP Data Interchange Format) é a troca de dados entre diferentes formatos que se baseia em um formato de texto padrão, utilizado para descrever diretórios, tendo a sua estrutura definida pela RFC 2849 (CARTER, 2003).
Os arquivos LDIF permitem a importação, exportação e backup dos dados de um servidor de diretório para o outro, sem que os mesmos utilizem uma mesma base de dados. Com esse padrão, para distribuir as informações entre eles, é possível utilizar
somente comandos padronizados, como por exemplo, adição, modificação, deleção e etc.
Atualmente existem dois tipos de arquivos LDIF. Um deles descreve um conjunto de entradas de diretórios, que serve para agregar diretamente a um diretório, enquanto que o outro tipo contém uma série de comandos de atualização que descrevem as mudanças que devem ser aplicadas aos atributos de entradas de um diretório.
2.10 OBJECT IDENTIFIER (OID)
Cada classe de objeto, ou tipo de atributo, é identificada de forma sintática, isto quer dizer que o OID (Object Identifier) é único em toda a estrutura de diretórios do LDAP. Isso é representado, por números decimais separados por pontos, dando origem a uma árvore hierárquica, ou mesmo, a uma DIT, propriamente dita (SUNGAILA, 2007). A IANA (Internet Assigned Number Authority) é a entidade responsável pelo registro de “sub-árvores” de OID’s (Tabela 1).
OID Utilização 1.1 Organizações OID 1.1.1 Elementos SNMP 1.1.2 Elementos LDAP 1.1.2.1 Tipos de atributos 1.1.2.1.1 Meus atributos 1.1.2.2 Classes de objetos 1.1.2.2.1 Minhas classes de objetos
Tabela 1. Alguns exemplos de Object Identifier
2.11 ATRIBUTOS
São identificados por um nome ou abreviatura que possui um único tipo com um ou mais valores, sendo o tipo associado a uma sintaxe que define o tipo de valor que pode ser armazenados no atributo (Tabela 2) (SUNGAILA, 2007).
Abreviatura Nome do atributo por extenso dn distinguished name cn commom name sn surname gn given name o organization name
ou organization unit name st state or province name
l Locality name
c country
jpegPhoto Fotografia e formato jpeg telephoneNumber Número telefônico
postalCode código postal
dc domain component
uid id de usuário
Tabela 2. Algumas abreviaturas de atributos, com seus respectivos nomes
2.12
ENTRADAÉ um unidade básica de informações armazenadas em um diretório que é composta por um conjunto de atributos que referenciam objetos que são organizados conforme uma DIT. Porém, como foi citado acima, existem arquivos texto, do tipo LDIF, que são utilizados para importar, exportar e realizar backup’s de dados dos diretórios, onde podem ser adicionadas várias entradas em somente um arquivo (Figura11) (PAPOTTI et. al., 2006).
2.13 OBJECT CLASS
É um conjunto de atributos referentes a uma entrada, sempre que uma entrada é definida, é atribuído uma ou mais classes e estes atributos podem ser opcionais ou obrigatórios.
Existem três tipos de classes de objetos, as estruturais, as auxiliares e as abstratas, nas quais, todas as entradas devem ter no mínimo uma classe de objeto estrutural e pode ter uma ou mais auxiliares. A abstrata possui uma especificação parcial da hierarquia de uma classe de objetos, visto que apenas subclasses estruturais ou auxiliares permitem esta classe de objetos. Um exemplo tirado do core.schema, a classe de objeto “person” (Figura 12), mostra os campos obrigatórios que são o “sn” e “cn” e os atributos opcionais: userPassword, telephoneNumber, seeAlso e description (SUNGAILA, 2007).
Figura 12. Classe de objeto person, retirada do core.schema
A abordagem quantitativa se originou a alguns conceitos de serviço de diretórios bem como, historia e origem do protocolo LDAP, delimitando toda a estrutura que está relaciona a representação dos diretórios. A vantagem para a implantação dessa tecnologia na questão da arquitetura LDAP, visando às fáceis manutenções e consistência dos dados. O aspecto de identificar e diferenciar as entradas para não gerar informações repetidas. A oportunidade de manutenção dos dados a partir de um arquivo texto (LDIF). A identificação de forma sintática de uma entrada, na qual designa que é o único em toda a estrutura de diretórios. As abreviaturas que são associadas a uma sintaxe que define o tipo de valores que podem ser armazenados no atributo e as restrições das entradas já existentes ou campos obrigatórios.
3 PROTOCOLO LDAP
O protocolo LDAP define operações para a realização de consultas e atualizações de diretórios, na qual são fornecidas para adição, remoção e modificação de uma entrada existente, ou mesmo, do nome dela.
Esse protocolo opera quatro tipos de modelos básicos, que podem ser armazenados nos diretórios, bem como, a determinação de qual será o destino desses dados (PAPOTTI et. al., 2006). Os modelos são:
• Modelo de Informação – define os tipos que podem ser armazenadas num diretório LDAP. A unidade básica da informação armazenada no diretório é chamada de entrada. Esse modelo herdado, quase sem alterações do X.500, é extensível. Ao definir novos object classes, pode-se adicionar a um diretório qualquer tipo de informação;
• Modelo de Nomes – este modelo define a forma como a informação no diretório LDAP pode ser organizada e referenciada. As entradas são organizadas numa DIT e divididas segundo uma distribuição geográfica e/ou organizacional. Cada entrada tem um DN que especifica o caminho da raiz até a entrada;
• Modelo de Segurança – define quais procedimentos podem ser tomados para evitar o acesso não autorizado às informações do diretório, como protocolos de encriptação e autenticação;
• Modelo Funcional – descreve as operações que podem realizar-se no diretório utilizando o protocolo LDAP;
3.1
OPERAÇÕES
As operações são baseadas na comunicação entre cliente e servidor LDAP, restringindo o envio e retorno das informações. A operação do tipo busca, por exemplo, pode abranger toda a árvore (uma busca com escopo da sub-árvore) ou apenas um ramo, sem descer ou subir para os demais. Além de especificar com filtros, quais entradas se desejam encontrar. É possível também, especificar quais
atributos desta entrada são procurados, porém se não forem especificados, todos serão retornados (TEIXEIRA; MERCER, 2000).
Existem tipos de operações que podem ser utilizadas de acordo com a necessidade, visto que depende do número de entradas e requisições, para uma ou várias operações.
Um servidor LDAP, ao encontrar apenas um valor para a operação de busca realizada, ele imediatamente retorna o mesmo. Na requisição, o cliente LDAP envia uma identificação (ID) única, “msgid” (identificador de mensagens), ou seja, somente uma informação que comprove a existência dele no diretório (PAPOTTI et. al., 2006). Esse ID é usado nas repostas para identificar as mensagens (Figura 13).
Figura 13. Recebimento de uma única entrada, estimada por PAPOTTI et. al. (2006)
Todavia, se o servidor encontrar diversos valores, os mesmos serão retornados em mensagens separadas (PAPOTTI et. al., 2006) (Figura 14). Para cada entrada retornada, existe um único nome, que é identificado como DN.
Figura 14. Recebimento de várias entradas, estimada por PAPOTTI et. al. (2006) Como o LDAP é orientado a mensagem, é possível realizar diversas operações ao mesmo tempo (Figura 15). Isto torna o protocolo mais flexível e eficiente, pois não
há a necessidade de esperar uma resposta do servidor antes de esperar outra operação, como no HTTP (PAPOTTI et. al., 2006).
Figura 15. Uma simples pesquisa no LDAP, estimada por PAPOTTI et. al. (2006) Note que o cliente envia outra solicitação sem aguardar pela finalização da primeira solicitação, com isso, não ocasionará nenhum problema, pois todas as mensagens são identificadas, tornando o protocolo LDAP mais ágil na pesquisa das informações, visto que uma mesma conexão aberta pode-se realizar várias consultas ao invés de abrir uma conexão a todo instante (PAPOTTI et. al., 2006). O LDAP é dividido em três tipos de operações: operação de pergunta, de atualização e de autenticação e controle (BAPTISTA, Miguel; DOMINGUES, M., 2005). 1) Operações de pergunta
a) ldapsearch - faz pesquisas das entradas no diretório;
b) ldapcompare - verifica se uma entrada contém um dado valor num atributo; 2) Operações de atualização
a) ldapadd - adiciona uma nova entrada; b) ldapdelete – apaga uma entrada existente; c) ldapmodify - altera uma entrada existente;
d) ldapmodrdn - renomeia uma entrada existente (modificar o RDN); 3) Operações de autenticação e controle
a) ldapbind - cliente se autentica com o servidor; b) ldapunbind - cliente encerra sessão com o servidor;
c) ldapabandon - cliente não está mais interessado nas respostas da requisição anteriormente enviada;
O cliente abre uma conexão com o servidor LDAP e envia uma operação “ldapbind”. Esta operação inclui o nome da entrada do diretório com a qual ele deseja autenticar-se, seguido das credenciais que serão usadas na autenticação (PAPOTTI et. al., 2006). As credenciais podem ser simples senhas ou até mesmo digitais. Após o servidor conferir se as credenciais são válidas, ele retorna uma mensagem de sucesso ao cliente, que posteriormente, enviará uma operação “ldapsearch”, visto que o servidor realizará a operação e retornará as duas entradas encontradas para o pedido (PAPOTTI et. al., 2006).
Porém, o servidor enviará uma mensagem com o resultado total. Com isso, o cliente envia uma operação “ldapunbind”, indicando que o cliente deseja desconectar-se, e por fim, o servidor obedecerá, terminando a conexão (PAPOTTI et. al., 2006) (Figura 16).
Figura 16. Estabelecimento de conexão, consultas e fechamento de uma conexão LDAP, estimada por PAPOTTI et. al. (2006)
3.2
SEGURANÇA
Um dos aspectos fundamentais do serviço de diretórios LDAP é segurança das informações armazenadas no servidor LDAP. De acordo com o modelo de segurança, são definidos, quais os procedimentos que devem ser tomados para evitar o acesso não autorizado às informações dos diretórios, como protocolos de autenticação e encriptação (PAPOTTI et. al., 2006).
Na atual versão do LDAP (LDAPv3), que trata a autenticação baseada nos modos de como os servidores são acessados. Com isso, utilizam-se frameworks SASL, bem como, múltiplos mecanismos de autenticação (SUNGAILA, 2007).
3.2.1 Métodos de Autenticação
A terceira e última versão do LDAP (LDAPv3), possuí métodos de autenticação que foram definidos na RFC 2829 (Authentication Methods for LDAP) (SUNGAILA, 2007). Nessa RFC, os servidores LDAP foram classificados em três grupos:
1) Públicos para somente-leitura, na qual permitem “login” anônimos, ou seja, sem que o usuário informe a senha.
2) Com autenticação usando senhas e mecanismo SASL DIGEST-MD5 (RFC 2831 – Using Digest Authentication as a SASL Mechanism).
3) Autenticação e criptografia de dados, utilizando StartTLS (RFC 2830 LDAPv3: Extension for Transport Layer Security) para camada de transporte segura e certificados com chaves públicas para autenticação de ambos os lados.
As interfaces de gerenciamento, em padrão UNIX (inclui Linux também) e Samba (para autenticar estações Windows), por exemplo, das contas de usuários são realizadas nos arquivos passwd e shadow. O processo de autenticação é realizado com o usuário digitando o login e a senha de acesso, ao passo que o sistema efetua a checagem da senha fornecida corresponde à oficial criptografada que é armazenada no arquivo-texto (/etc/passwd). Esse processo baseia-se no conceito de que o usuário é realmente o solicitado, e a senha de acesso está correta. Para que esse processo funcione adequadamente, foram desenvolvidas aplicações, levando em consideração estes procedimentos (login, ftpd etc) (SUNGAILA, 2007).
Desde então, vários métodos de autenticação têm sido criados, desenvolvidos, testados e colocados em produção, incluindo mecanismos complicados de substituição do passwd, dispositivos de hardware como o Smart Cards e outros. O problema gerado com isto é que, a cada novo esquema de autenticação apresentado, todos os aplicativos envolvidos em autenticação de usuários, devem ser reescritos para suportá-los (SUNGAILA, 2007).
A partir desse contexto, pode-se utilizar o PAM (Pluggable Authentication Modules) que equivale a dizer que é um método flexível de checagem de itens de segurança quando um usuário efetua logon.
O PAM foi criado pela Sun Microsystems para oferecer um método de desenvolver aplicações que sejam independentes do mecanismo de autenticação em uso. Estas aplicações passam a solicitar ao PAM que o usuário seja autenticado. Este, por sua vez, utiliza o módulo de autenticação definido pelo administrador local, durante a fase de configuração do equipamento, e é totalmente transparente para as aplicações (o login é uma destas) (CERQUEIRA, 2005). Todas as aplicações do PAM foram publicadas pela Sun no formato de RFC, na qual o Linux baseia-se para a utilização.
Os módulos de autenticação PAM foram divididos em quatro categorias distintas (SUNGAILA, 2007), definindo os tipos disponíveis:
• auth – faz a validação do usuário, verificando a identidade por várias maneiras: checando usuário e senha, método mais simples e mais usual, utilizando a verificação biométrica como impressão digital, timbre voz ou imagem da retina. Pode ainda limitar o número de usuários ou restringir o acesso do root em algum serviço.
• account - verifica se o usuário pode utilizar o serviço na qual está tentando autenticação, checando o horário da conexão, o grupo do usuário, o dia da semana, o IP (Internet Protocol) de origem ou ainda o número de logins simultâneos.
• passwd – entra em funcionamento durante o processo de troca de senhas dos usuários. Módulos deste tipo incluem a cracklib que checa se a senha do usuário é fraca ou se pertence a algum dicionário conhecido, melhorando a segurança das senhas.
• session – cria o ambiente do usuário, habilitando dispositivos de hardware aos quais o usuário tenha direito de acesso, como cdrom, placas de áudio e outros, mapeia sistemas de arquivos remotos, efetua registros em log, além de criar recursos como o diretório pessoal do usuário caso este não exista. Porém, determina o que será necessário para que o usuário se conecte.
De forma ampla, o PAM é um conjunto de bibliotecas fornecido com a maioria das distribuições Linux moderno e é instalado por padrão no RedHat Linux. As bibliotecas do PAM fornecem uma interface consistente a um protocolo de autenticação. Uma aplicação pode usar essas bibliotecas para permitir o uso de
qualquer protocolo de autenticação dentro da aplicação. Assim, se o administrador de sistema mudar, por exemplo, a autenticação de /etc/passwd para o LDAP, a aplicação não precisa ser reescrita ou recompilada (CERQUEIRA, 2005). Exige-se um módulo para cada sistema de autenticação.
O PAM somente fornece parte da informação necessária para controlar os usuários em um sistema Linux. Além de permitir checagem se um usuário entrou com a senha correta, um sistema Linux precisa de outras informações, como o ID numérico do usuário, o diretório, o shell padrão e etc. Esta informação, normalmente é armazenada no arquivo /etc/passwd, pode ser determinada através de uma interface de sistema conhecida como NSS (Name Service Switch) (CERQUEIRA, 2005).
3.2.2 Métodos de Criptografia
Uma forma de manter a confidencialidade dos dados é através da criptografia. Ela fornece técnicas que permitem a codificação e decodificação dos dados, onde os mesmos podem ser transmitidos e armazenados sem que haja alterações ou a exposição à entidade não autorizada. O objetivo da criptografia é prover uma comunicação segura, garantindo aos serviços a confidencialidade, autenticidade e integridade.
A criptografia de chave pública e implementações dentro de um servidor LDAP baseado num sistema de segurança, tem sido possível devido às redes e protocolos de aplicações serem padronizados. Os protocolos mais importantes são SSL e TLS. O SSL/ TLS (última versão do SSL) é um sistema aberto, protocolo não proprietário desenvolvido pela Netscape para prover segurança durante as comunicações sensíveis. Este é aceito pelo padrão WEB para a comunicação entre cliente-servidor criptografada e autenticada, podendo rodar em baixo dos protocolos de aplicação HTTP, SNMP, FTP, LDAP e Telnet [Baltimore] (COUTINHO; MSILVA, 2006). Este é seguro, rápido e facilmente adaptado a outros protocolos WEB (Figura 17).
Figura 17. LDAP usando SASL com SSL/TLS, retirado do (BRANCO, 2004) O TLS é um padrão do IETF, proposto pela Microsoft, que é definido como um protocolo que fornece privacidade de comunicação e segurança entre duas aplicações que comunicam-se através de uma rede. O TLS fornece um canal seguro através da encriptação da comunicação e permite aos clientes autenticarem-se nos servidores ou, opcionalmente, que os servidores autentiquem os clientes (KANIES, 2001).
Os clientes que usam TLS na comunicação, as mensagens não serão decifradas caso sejam capturadas e nem alteradas (homem do meio), bem como, podem autenticar o servidor e verificar a autenticidade de servidores nos quais ele já está conectado, usando certificados com chaves públicas (KANIES, 2001).
Conforme foi citado anteriormente, o NSS é uma interface de sistema, que pode guardar as informações do usuário, na qual, delimita um conjunto de bibliotecas designadas para o suporte de desenvolvimento de uma plataforma de segurança – aplicações de servidores e clientes habilitados. A construção de aplicações com NSS podem suportar certificados de SSL v2 e v3, TLS e outros padrões de segurança (SUNGAILA, 2007).
3.2.3 Modelo de Controle de Acesso
O modelo define os direitos de acesso as informações do diretório para cada usuário ou grupo, como por exemplo, somente leitura de nomes para usuário administrador, alteração de descrição para todos os usuários e leitura de informações básicas do diretório para usuário anônimo (SUNGAILA, 2007).
Porém, esse controle de acesso não foi padronizado pela IETF (PAPOTTI et. al., 2006), por que ainda está sendo definido um padrão. Cada fabricante tem um padrão distinto, com muito trabalho de migração, visto que às vezes é necessária a mudança de fabricante.
3.3
OTIMIZAÇÕES DO LDAP
Além de todas as otimizações de serviços de organização de informações, o LDAP oferece também recursos para a replicação de dados em caso das mesmas serem apagadas ou alteradas por intrusos. Um exemplo de um servidor para Linux que auxilia o LDAP (mais precisamente o SLAPD – servidor que pode ser executado em diversas plataformas), provendo a replicação do banco de dados é o SLURPD (um daemon para ajudar o SLAPD a replicar seus serviços). O SLAPD e o SLURPD comunicam-se através de um simples arquivo texto, ou seja, arquivo LDIF, que é utilizado para registrar as mudanças (SUNGAILA, 2007).
Com isso, é utilizado um outro conceito, que é o de diretórios distribuídos, juntamente com a replicação, a fim de diminuir os custos e também aumentar a performace da busca de informação em formato de árvore distribuída.
3.3.1 Replicação do serviço de diretórios
Conceito de prover mecanismos de tolerância a falhas, a fim que manter o acesso as informações dos usuários sempre íntegras.
A replicação de diretórios pode ocasionar pontos de falha quando muitos computadores acessam somente um servidor (PAPOTTI et. al., 2006) (Figura 18).
Figura 18. Pontos de Falha da Replicação de Diretórios, estimada por (PAPOTTI et. al., 2006)
Para solucionar tal problema, é necessário usar o conceito de diretórios replicados para usar uma redundância quando for necessário (Figura 19).
Figura 19. Redundância de Diretórios, estimada por (PAPOTTI et. al., 2006) Quando se tem uma falha no serviço, o outro servidor entra em operação de forma automática (Figura 20).
Figura 20. Ponto de Falha e Troca de Servidor, estimada por (PAPOTTI et. al., 2006)
Após falhas no serviço principal (Servidor A) a aplicação de diretório será habilitada, de forma automática, uma replicação para outro serviço (Servidor B).
3.3.2 Diretórios distribuídos
A distribuição de diretórios visa à redução dos pontos de falhas, além de prover menor consumo de banda e tempo quando uma consulta é realizada. O principal benefício é a possibilidade de redução de custos com hardware.
Uns dos problemas abrangentes nos diretórios distribuídos são muitos computadores acessando o local que reside à informação. Tempo elevado e utilização do hardware para leitura (Figura 21).
Figura 21. Vários Clientes de Diretórios acessando somente um Servidor, estimada por (PAPOTTI et. al., 2006)
Para a solução desse problema é necessário a utilização de vários computadores na formação da árvore de diretórios, agregando os clientes em servidores replicados, a fim de agilizar a busca e evitar a perda das informações (Figura 22).
Figura 22. Vários Clientes de Diretórios acessando Servidores Replicados, estimada por (PAPOTTI et. al., 2006)
3.4
OPENLDAP
No inicio a maioria dos servidores LDAP eram comerciais, como o servidor de diretórios da Netscape.
Segundo o SUNGAILA (2007), no mercado encontram-se algumas implementações de serviços de diretórios, entre eles têm os de cunho comercial – IBM Tivoli Directory Server, Microsoft ADS e Novel Directory, Netscape Directory Server e Sun Java System Directory Server – e os de padrão aberto – OpenLDAP.
A primeira versão OSS era o servidor LDAP da Universidade de Michigan. Mas eventualmente, o código da Universidade deixou de ser atualizado e no lugar dele passou a ser utilizado o OpenLDAP que traz este protocolo ao alcance dos usuários Linux , com o intuito de testar a versatilidade do LDAP com um código atualizado, ao mesmo tempo que mantém compatibilidade de API (Application Programming Interface) com outros programas (v. Capítulo 4). O OpenLDAP foi codificado para ser escalável, fornecendo suporte para replicação de servidores, e uma escolha de servidores de bancos de dados de backend (servidor que está rodando um serviço de diretórios) (CARTER, 2003).
O OpenLDAP é um esforço colaborativo da comunidade Open Source para desenvolver um sistema de aplicações LDAP. O fundador deste projeto é o americano Kurt Zeilenga. Hoje existem vários desenvolvedores engajados neste sistema que está se tornando um padrão universal (SUNGAILA, 2007).
3.5
FERRAMENTAS PARA GERENCIAR UM SERVIDOR LDAP
Até o momento foi caracterizado o funcionamento, a arquitetura do servidor LDAP, os conceitos que abrange essa tecnologia. Porém, existem ferramentas Open Sources que são utilizadas no gerenciamento dos diretórios LDAP, tornando o processo mais simples e eficiente (SUNGAILA, 2007).
Essas ferramentas podem ser com interface gráfica, bem como, módulo Web para administração do servidor LDAP. A visualização é de forma hierárquica da árvore LDAP, na qual são intuitivos e fáceis de serem configurados, e a cima de tudo, livres, ou seja, gratuitos. A vantagem relaciona-se ao funcionamento para quaisquer sistemas operacionais, e também pelo suporte internacional de oito idiomas.
Existem alguns programas aptos para gerenciar um servidor LDAP. As mais indicadas pela versatilidade e desenvolvimento são GQ e Luma via interface gráfica do Linux, com muitos recursos interessantes como inspeção de schemas (SUNGAILA, 2007). O aplicativo GQ pode ser obtido no site: http://biot.com/gq, e o Luma no http://luma.sourceforge.net.
Um dos aplicativos mais práticos para o visualização e gerenciamento das informações dos diretórios é o acesso via Web chamado phpLDAPadmin , que pode ser obtida no site oficial em http://www.phpldapadmin.com.
Um dos pontos fortes do phpLDAPadmin é a criação de uma série de objetos por meio de opções predefinidas como, por exemplo, contas de usuários padrão POSIX (Portable Operating System Interface) para estações Linux ou padrão Samba para autenticação de uma rede Windows, criação de novas unidades organizacionais ou grupos de usuários, além de uma série de objetos específicos para os diretórios. Por último, permite a criação de entradas customizadas pelo usuário, de modo que, pode-se escolher qual objectClass e quais atributos irão compor o registro (SUNGAILA, 2007). Os conteúdos do diretórios expandem detalhes de toda a estrutura da árvore (DIT), confome representado na Figura 23.
Figura 23. Detalhes da estrutura do diretório e tela de criação de novas entradas no diretório usando phpLDAPadmin
Além dos aplicativos mencionados, pode-se contar com o LDAP Admin, que é uma ferramenta gráfica que roda em estação Windows e pode ser obtida no site oficial em http://ldapadmin.sourceforge.net. Este aplicativo é distribuído em dois pacotes: um com os modelos de dados (templates) e outro com arquivo executável da aplicação (SUNGAILA, 2007).
Após efetuar a conexão com o servidor LDAP através desse aplicativo, na Figura 24, exibe a estrutura de diretórios.
Figura 24. Administração do diretório com LDAP Adm
O ponto forte desse aplicativo é a permissão da visualização de todos os atributos que uma entrada suporta, ou mesmo, editá-las (Figura 25);
Figura 25. Edição avançada de atributos com o LDAP Admin
De acordo com os aplicativos demonstrados, para que os usuários tenham a permissão de editarem as entradas dos diretórios é necessário que as bibliotecas de
autenticação (PAM e NSS) estejam configuradas. Se isso não ocorrer, o servidor LDAP permitirá somente acessos anônimos, ou seja, somente leitura dos dados. Diante de todo conceito do protocolo LDAP, o uso do serviço de diretórios OpenLDAP é uma alternativa de integração, aplicável a sistema de software, e segurança das contas de usuários a fim de realizar fáceis manutenções que distribui os diretórios em forma hierárquica em árvore (DIT), com uma representação geográfica facilitando a visualização e busca dos dados. A partir disso, a criptografia e autenticação dos usuários foi uma maneira eficaz de garantir a segurança e busca de informações, visto que, podem ser operadas por meio de aplicativos gratuitos (PHPLdapAdmin, LDAPadmin, dentre outros).
Com a utilização da replicação e distribuição de diretórios, evitam-se as colisões e tolerâncias de informações, demonstrando mais eficiência no acesso aos diretórios. Na apresentação deste capítulo, demonstrou os modelos básicos de armazenamento de diretórios, as operações baseadas na comunicação entre cliente e servidor e a segurança para evitar os acessos não autorizados das informações dos diretórios. E também os métodos de autenticação e criptografia, bem como, o modelo de controle de acesso, visando às otimizações dos serviços de organização das informações, como o mecanismo de tolerância de falhas (replicação dos serviços de diretórios) e redução dos pontos de falhas (diretórios distribuídos). Logo após, foi abordado o serviço de diretórios OpenLDAP e as ferramentas para gerenciamento dos diretórios no servidor LDAP.
4 ARQUITETURA DE DIRETÓRIOS
A abordagem da arquitetura de diretórios visa algumas aplicações que o LDAP exerce. Porém, a autenticação única facilita a integração com outros serviços por meio de uma identificação e senha, na qual é possível acessar diversos recursos de uma rede e não mais para cada serviço.
A partir desse conceito, a construção de uma arquitetura de diretórios da FEMA (Fundação Educacional do Município de Assis), possibilitará a centralização da autenticação dos usuários de sistemas, na qual tornará as consultas e gerenciamentos mais eficientes. Todos os serviços fornecidos pelo provedor FEMAnet (provedor da própria instituição), dentre eles (webMail, autenticação DNS, FTP, Wireless e etc), servidores de intranet da FEMA (sistemas legados, aplicativos web, Proxy, Samba e outros).
4.1
CONSIDERAÇÕES
Para averiguar se a arquitetura será eficiente para a autenticação dos usuários de sistemas no diretório LDAP, serão realizados testes para avaliação de desempenho em busca das identificações válidas no serviço de diretórios, proporcionando expectativas para novas implementações.
A arquitetura de diretórios da FEMA, a ser demonstrada, está constituída de clientes Windows e Linux, aplicativos em sistemas Web implementados na linguagem Java e autenticação de usuários no Samba, dentre outros recursos de rede que interceptam ao serviço de diretórios OpenLDAP (Figura 26).
Figura 26. Arquitetura da FEMA
Os testes a serem demonstrados e avaliados serão, somente, a partir do aplicativo implementado na linguagem Java, de forma que o mesmo foi criado através da IDE (Intelligent Drive Electronics ou também Integrated Drive Electronics) Netbeans (versão 6.0). Para a construção de uma interface Web em JSP (Java Server Pages) com a utilização de servlets para o processamento dos usuários a serem autenticados, ou mesmo, inseridos ou removidos no diretório LDAP. Para que a aplicação se comunique com os diretórios, foi utilizado uma API (Application Programming Interface) Java chamada JNDI (Java Naming and Directory Interface), que acessa serviço de diretórios OpenLDAP. Ela permite que aplicações descubram e obtenham dados ou objetos através de um nome. Assim como todas as APIs Java, ela é independente de plataforma. Adicionalmente, ela especifica uma interface de serviço – SPI (Service Provider Interface), na qual permite que softwares de serviço de diretório suportem o framework (PIRES, 2003).
A API JNDI acessam recursos externos, como base de dados, filas ou tópicos JMS (Java Message Service) e componentes JEE (Java Enterprise Edition). A API disponibiliza um mecanismo para ligar um objeto a um nome, bem como, uma interface padronizada de busca de objetos no serviço de diretório, e uma outra, de eventos que permite que um usuário saiba quando uma entrada (nome mais objeto) foi modificada, e por fim, as extensões que suportam as capacidades do padrão LDAP (PIRES, 2003).
