JEDSON ZENDRON FIGUEIREDO AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE SISTEMAS INTEGRADOS A SERVIÇOS DE DIRETÓRIOS

Transcrição

1 JEDSON ZENDRON FIGUEIREDO AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE SISTEMAS INTEGRADOS A SERVIÇOS DE DIRETÓRIOS Assis 2008

2 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

3 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

4 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.

5 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.

6 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. Palavras-chave: LDAP. Autenticação. Serviço de Diretórios.

7 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. Keywords: LDAP. Authentication. Service Directories.

8 LISTA DE ILUSTRAÇÕES Figura 1 História do LDAP Figura 2 Utilizando DIXIE para se comunicar com diretórios X Figura 3 Modelo gateway LDAP/DAP Figura 4 Cliente do X Figura 5 DAP (Directory Access Protocol) Figura 6 Pilha de Protocolos Figura 7 Arquitetura LDAP Figura 8 Representação de parte de um Diretório LDAP Figura 9 RDNs idênticos Figura 10 DN é uma seqüência de RDN s Figura 11 Exemplo de entradas em um arquivo LDIF Figura 12 Classe de objeto person, retirada do core.schema Figura 13 Recebimento de uma única entrada Figura 14 Recebimento de várias entrada Figura 15 Uma simples pesquisa no LDAP Figura 16 Estabelecimento de conexão, consultas e fechamento de uma conexão LDAP Figura 17 LDAP usando SASL com SSL/TLS Figura 18 Pontos de Falha da Replicação de Diretórios Figura 19 Redundância de Diretórios Figura 20 Ponto de Falha e Troca de Servidor Figura 21 Vários Clientes de Diretórios acessando somente um Servidor Figura 22 Vários Clientes de Diretórios acessando Servidores Replicados Figura 23 Detalhes da estrutura do diretório e tela de criação de novas entradas no diretório usando phpldapadmin Figura 24 Administração do diretório com LDAP Adm Figura 25 Edição avançada de atributos com o LDAP Admin Figura 26 Arquitetura da FEMA Figura 27 Estrutura de Diretórios da FEMA Figura 28 Variáveis que determinam a quantidade de Usuários de acordo com a Proporção... 53

9 Figura 29 Criação dos Usuários no Diretório LDAP, para cada Grupo, dependendo da proporção Figura 30 Manutenção das Contas de Usuários Figura 31 Forma A e B de Autenticações de Usuários 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 Figura 33 Integração dos Usuários de Sistemas ao Serviço de Diretórios OpenLDAP Figura 34 Caso de Uso do Modelo de Negócio Figura 35 Diagrama de Classes Beans e LDAP Figura 36 Página de Autenticações dos Usuário para efetuar o acesso ao Aplicativo Demonstrativo Figura 37 Aplicativo Demonstrativo Figura 38 Permissões de Ação do Usuário Simples que acessou ao Aplicativo Demonstrativo Figura 39 Algoritmo que Insere os Usuários no diretório LDAP, de acordo com a Proporção 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 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 Figura 42 Algoritmo que Apaga todos os Usuários do diretório LDAP, de acordo com a Proporção Figura 43 Avaliação A da Autenticação de Mil Usuários com Conexão de Internet Dial Up Figura 44 Avaliação A da Autenticação de Mil Usuários com Conexão de Internet Rede Local Figura 45 Avaliação A da Autenticação de Cem Mil Usuários com Conexão de Internet Wireless Figura 46 Avaliação B da Autenticação de Dez Mil Usuários com Conexão de Internet Rede Local Figura 47 Autenticação de Usuário... 78

10 Figura 48 Manutenção de Dados dos Usuários Figura 49 Movimentação das Permissões de Ação dos Usuários Figura 50 Relatório das Permissões de Ação aos Grupos e Usuários Figura 51 Autenticação do Usuário no Diretório LDAP Figura 52 Manutenção de Usuários de Sistemas Integrada ao Diretório LDAP... 81

11 LISTA DE TABELAS Tabela 1 Alguns exemplos de Object Identifie Tabela 2 Algumas abreviaturas de atributos, com seus respectivos nomes Tabela 3 Resultados do Tempo de Autenticações de Usuários... 56

12 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

13 SSO DN CN RDN LDIF OID IANA SN GN O OU ST L C DC UID MSGID IP PAM NSS POSIX FEMA IDE JSP JNDI JEE JMS API SPI IEEE ADSL AJAX XML MVC Single Sing On Distinguished Name Common Name Relative Distinguished Name LDAP Data Interchange Format Object Identifier Internet Assigned Number Authority Surname Given Name Organization Name Organization Unit Name State or Province Name Locality Name Country Domain Component User Identification Identificador de mensagens Internet Protocol Pluggable Authentication Modules Name Service Switch Portable Operating System Interface Fundação Educacional do Município de Assis Intelligent Drive Electronics ou também Integrated Drive Electronics Java Server Pages Java Naming and Directory Interface Java Enterprise Edition Java Message Service Application Programming Interface Service Provider Interface Institute of Electrical and Electronics Engineers Asymmetric Digital Subscriber Line Asynchronous Javascript And XML Extensible Markup Language Model View Controller

14 UML JUDE Unified Modeling Language Java and UML Developers Environment

15 SUMÁRIO 1 INTRODUÇÃO JUSTIFICATIVA E MOTIVAÇÕES OBJETIVOS... Erro! Indicador não definido. 1.3 ESTRUTURA DO TRABALHO... Erro! Indicador não definido. 2 CONCEITOS DE SERVIÇOS DE DIRETÓRIOS O QUE É UM SERVIÇO DE DIRETÓRIO? O QUE É LDAP? HISTÓRIA DO LDAP ORIGEM DO LDAP Diretório X Cliente do X DAP Pilhas de protocolos Versões POR QUE USAR LDAP? DIRETÓRIO LDAP SCHEMA DISTINGUISHED NAMES (DN) O QUE É LDIF? OBJECT IDENTIFIER (OID) ATRIBUTO ENTRADA OBJECT CLASS... 33

16 3 PROTOCOLO LDAP OPERAÇÕES SEGURANÇA Métodos de Autenticação Métodos de Criptografia Modelo de Controle de Acesso OTIMIZAÇÕES DO LDAP Replicação do serviço de diretórios Diretórios distribuídos OPENLDAP FERRAMENTAS PARA GERENCIAR UM SERVIDOR LDAP ARQUITETURA DE DIRETÓRIOS CONSIDERAÇÕES AVALIAÇÃO DA AUTENTICAÇÃO DE USUÁRIOS ESTATÍSTICA DA ESTRUTURA DE DIRETÓRIOS DA FEMA APLICATIVO DEMONSTRATIVO CONSIDERAÇÕES MODELAGEM E APRESENTAÇÃO DO APLICATIVO CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS 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 ANEXO D DIAGRAMAS DE SEQÜÊNCIA CAPÍTULO

17 17 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

18 18 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.

19 19 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.

20 20 E por fim, as considerações finais, demonstrando os resultados da pesquisa, vantagens e desvantagens, ou mesmo, a contribuição com outros pesquisadores.

21 21 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.

22 22 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

23 23 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).

24 24 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

25 25 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) 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).

26 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) 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) 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

27 27 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) 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).

28 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 , 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). Figura 7. Arquitetura LDAP (

29 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.

30 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

31 31 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 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 Elementos SNMP Elementos LDAP Tipos de atributos Meus atributos Classes de objetos 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).

32 32 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). Figura 11. Exemplo de entradas em um arquivo LDIF

33 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.

34 34 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

35 35 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

36 36 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;

37 37 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).

38 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.

39 39 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

40 40 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) 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).

41 41 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) 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).

42 42 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 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).

43 43 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).

44 44 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) 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).

45 45 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)

46 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.

47 47 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: e o Luma no 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 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

48 48 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 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

49 49 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.

50 50 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).

51 51 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).

52 52 Diante disso, a arquitetura definida conterá no serviço de diretórios OpenLDAP, cinco grupos: Alunos, Professores, Funcionários, Visitantes e Externos (Figura 27). Em cada grupo terá um número de usuários, conforme a quantidade referente à instituição. Figura 27. Estrutura de Diretórios da FEMA A quantidade nem sempre será a mesma. Após a análise de performance, constatará se a autenticação de usuários num diretório LDAP será eficiente, dentre várias autenticações simultâneas, independente da quantidade de usuários contido na estrutura de diretórios definida para esta avaliação. 4.2 AVALIAÇÃO DA AUTENTICAÇÃO DE USUÁRIOS A abordagem quantitativa foi fundamentada na criação do aplicativo Java, comentado anteriormente, com quatro tarefas divididas em duas fases, uma dessas efetua a manutenção de usuários simples de um servidor LDAP, no aspecto de criação e remoção das contas (tarefas) (Figura 30). Porém, as mesmas serão criadas por loops (repetição de processo a partir de uma condição verdadeira) contando de 1 a 1000 (para o primeiro teste), de 1 a (para o segundo teste) e de 1 a (para o terceiro teste), dependendo da proporção estabelecida pelo teste x (Figura 28). Essa proporção está relacionada a uma variável x que designa a quantidade de usuários que existem ou não nos diretórios.

53 53 Figuras 28. Variáveis que determinam a quantidade de Usuários de acordo com a Proporção De acordo com a variável x (Proporção) demonstrada na Figura 28, se o mesmo receber o valor igual a 1, então será criado 1000 usuários subdivididos a partir da multiplicação das constantes fixas na prototipação das variáveis de cada grupo. Por exemplo, na grupo Visitantes conterá 7 usuários, devido a multiplicação da proporção com o valor inteiro 7. Assim será para usuários, com a proporção igual a 10 e com o valor x referente a 100. Figura 29. Criação dos Usuários no Diretório LDAP, para cada Grupo, dependendo da proporção

54 54 A classe que interage com o serviço de diretórios é chamada de ClassLDAP. Ela foi criada, ou seja, estruturada para executar ações de autenticação e manutenção dos usuários LDAP. Porém, após estância a mesma, o método construtor receberá a identificação do usuário (uid), ou mesmo o login, na qual será a palavra usuário sucedido do contador, já a senha será uma seqüência de caracteres, como por exemplo, J-%&i4/ (essa seqüência é mesma para todos os usuários) concatenada com o mesmo contador. No entanto, a tarefa que insere, remove ou autentica os usuários, serão a partir dos mesmos loops, mas é modificado somente o método que corresponde à ação. Os códigos fontes estão apresentados no Anexo A. Para a realização dos testes, foram estruturados os usuários dessa forma, para que a base de dados ficasse completamente carregada de caracteres, simulando como se fossem usuários comuns. Figura 30. Manutenção das Contas de Usuários

55 55 A outra fase é constituída também de duas tarefas na qual determinarão os tempos de resposta em segundos das autenticações simultâneas de usuários, baseadas nas quantidades definidas acima. Os testes de autenticação foram realizados conforme a abertura e fechamento da conexão com o servidor LDAP. A primeira tarefa constituise em somente uma abertura e um fechamento da conexão, ou seja, abre a conexão e autentica todos os usuários depois realiza o fechamento. Já a outra tarefa, a cada autenticação, realizou-se a abertura e fechamento da conexão (Figura 31). Figura 31. Forma A e B de Autenticações de Usuários Após a criação das contas de usuários, referentes à quantidade foram realizados cinco testes de autenticação de usuários com o intervalo de 20 minutos. A partir disso, a cada teste foi estipulado tipos de conexão à Internet, como também, a velocidade fornecida. Essas conexões foram: dial up (linha discada), wireless padrão IEEE (Institute of Electrical and Electronics Engineers) bg (rádio digital), ADSL (Asymmetric Digital Subscriber Line) e rede local, com velocidades variando de 56kbps a 100mbps.

56 56 Os testes práticos poderão ser visualizados no Anexo B com a representação das autenticações com resultados do tempo de resposta no OutPut, ou seja, na saída da IDE NetBeans. Os resultados estão relacionados a uma tabela abaixo com as quantidades definidas de usuários, os tipos de conexões e as duas formas de autenticações, sendo uma, a autenticação com conexão aberta para todos os usuários e fechada no final do processo (A), e a outra para cada usuário, fechando a cada autenticação (B) (Tabela 3). Esses valores serão a média dos cinco testes, com uma margem aproximada, em segundo. Quantidade Tempo de Resposta em Segundos de Usuários Dial Up (56kbps) Wireless (256kbps) ADSL (2MB) Rede Local (100MB) 1 a 1000 A 189 A 27 A 74 A 4 B 828 B 178 B 241 B 33 1 a A 1548 A 117 A 884 A 51 B B 1191 B 3734 B a A A 1641 A 8011 A 673 B B B B 7863 Tabela 3. Resultados do Tempo de Autenticações de Usuários Esses resultados foram obtidos através de um Cliente (Windows) (local do aplicativo Java) com o processador Core 2 Duo e 2G de memória RAM e um servidor LDAP com um processador Pentium 1.8 e 256MB de RAM, contendo velocidade de Internet de 512kbps. Mas, conforme citado em seções anteriores, a autenticação de usuários num diretório LDAP, não exige poder computacional para a realização dessas tarefas. 4.3 ESTATÍSTICA DA ESTRUTURA DE DIRETÓRIOS DA FEMA A tabela demonstrada anteriormente comprova que o LDAP autentica cada um de seus usuários em menos de 1 segundo. Mas, qual será a forma, ou seja, tipo de conexão a Internet mais adequada para autenticar os usuários LDAP a fim de integrar os mesmos às contas de sistemas? Logo abaixo estão relacionados, estatisticamente, os resultados dos testes alimentados na tabela acima (Figura 30).

57 57 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 A Figura 32 demonstra que a realização de autenticações de usuários LDAP é muito eficiente, com isso nem sempre haverá perda de informações, visto que poderão decorrer conforme a distância das informações, ou mesmo, pela escassez da velocidade da conexão a Internet. A autenticação com abertura e fechamento de conexões no servidor LDAP, somente após todos os usuários serem identificados (A), foi fundamental, por que apresentou um tempo de resposta muito rápido do que a abertura e fechamento para cada autenticação (B). Com isso, o LDAP além de centralizar as informações das contas de usuários, ele disponibiliza prontamente, de forma rápida e concisa, a resposta das autenticações. Neste capítulo foi apresentada a avaliação da autenticação dos usuários no diretório LDAP, a partir de dois algoritmos estruturados de acordo com a abertura e fechamento da conexão com o servidor LDAP, a fim de realizar seqüencialmente a autenticação em até cem mil usuários, através de quatro conexões a Internet. E o intuito desses testes estava relacionados numa alternativa de implementação das funcionalidades de uma integração do serviço de diretórios a sistema de software.

58 58 5 APLICATIVO DEMONSTRATIVO O aplicativo a ser demonstrado está relacionado à manutenção das contas de usuários de sistemas, integrada a serviço de diretórios OpenLDAP, com o intuito de centralizar as informações dos mesmos, para que os sistemas e outros recursos de rede, possam utilizar as mesmas credenciais para validar na autenticação. Com relação à arquitetura definida para a FEMA, citadas no Capítulo 4, os processos de autenticação dos usuários são de informações desencontradas, devido cada um dos serviços possuírem maneiras diferentes para controle de acesso. No laboratório de informática da instituição, atualmente estão disponíveis aos usuários, um servidor Samba para a liberação de espaços no disco rígido do mesmo para armazenamento de arquivos, e um servidor Proxy para controlar os acessos não autorizados, a sites restritos, pela instituição. E para a informatização dos processos da instituição, existem aplicativos Web que disponibilizam informações relacionadas, principalmente, a professores, alunos e funcionários, as quais são apresentadas as notas e faltas dos alunos, planejamento de aulas dos professores, requisições de equipamentos para setores, entre outras funcionalidades. E também os serviços oferecidos pelo provedor FEMAnet (provedor da instituição), as quais podem ser controlados por um único usuários (Figura 33). Para a unificação desses processos, motivaram-se a idéia da centralização das informações dos usuários para facilitar a manutenção das contas, devido os métodos de autenticações serem de maneiras diferenciadas, por causa dos diferentes bancos de dados. E com o aproveitamento desse conceito de integração, no aplicativo demonstrativo serão efetuadas permissões de ação dos eventos aos grupos e usuários (acessar, incluir, excluir e alterar) a fim de que os aplicativos e os recursos de rede utilizem as mesmas informações dos usuários e que possam restringir as permissões de acesso aos eventos dos sistemas de software.

59 59 Figura 33. Integração dos Usuários de Sistemas ao Serviço de Diretórios OpenLDAP As manutenções serão realizadas pelo usuário administrador do LDAP, devido o mesmo conter as permissões de toda estrutura de diretórios, a fim de realizar a iteração, com os diretórios, no aspecto de criação e remoção dos grupos (Organization Units - ou) e usuários (User Identification - uid). Para o acesso ao aplicativo demonstrativo, após a autenticação válida no diretório LDAP, o DN do usuário irá para a session do servidor Web, a fim de restringir os acessos não autorizados, bem como, a busca das permissões de ação do usuário que acessou ao sistema. Todos os usuários que pertencem às unidades organizacionais (ou), ou seja, membros de grupos, só terão acesso a uma página que contem os informativos atribuídos pelo usuário administrador do LDAP, visto que os usuários simples visualizarão e acessarão somente as informações relacionadas a cada um deles. 5.1 CONSIDERAÇÕES O aplicativo demonstrativo foi implementado com as mesmas considerações, de linguagem de programação e componentes de acesso aos diretórios, utilizadas no aplicativo de avaliação da autenticação, relatado no Capítulo 4. Porém, foi

60 60 implantado também, à tecnologia AJAX (Asynchronous Javascript And XML) para processar somente as informações necessárias e permanecer as que ainda serão utilizadas na página, a fim de tornarem-se as pesquisas mais rápidas. O AJAX é uma ferramenta que faz analogia a requisição de javascript e XML (Extensible Markup Language) assíncrona. Foi utilizado o modelo de padrão de projetos MVC (Model View Controller), que tem por objetivo básico separar a lógica de negócio da apresentação. O modelo MVC é subdividido em três camadas físicas, delimitando o modelo, a visão e o controle, na qual fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo. A visão está relacionada a tela que iterage com o usuário (MACORATTI, 2005). 5.2 MODELAGEM E APRESENTAÇÃO DO APLICATIVO O aplicativo foi modelado por uma linguagem chamada UML (Unified Modeling Language), na qual não é proprietária de terceira geração, e basicamente, permite que desenvolvedores visualizem os produtos do trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos (SILVA, 2001). O JUDE (Java and UML Developers Environment) é uma IDE que foi utilizada para a modelagem dos dados (UML) criada com Java. Com o IDE JUDE é possível realizar uma modelagem de dados complexa, na qual apresenta os dados para o usuário de forma clara e ainda possível a vantagem do layout ser bem intuitivo (CAMPOS, 2006). Alguns diagramas desenvolvidos nessa IDE, poderão ser visualizados nos Anexos C e D. Para a apresentação dos dados no aplicativo demonstrativo foi utilizado o banco de dados PostegreSQL 8.2, devido o mesmo ser gratuito e demonstrar fácil implantação

61 61 com a linguagem Java, a partir de uma biblioteca de comunicação disponibilizada pelo mesmo. A representação do modelo de negócio está relacionada com as funcionalidades de o usuário administrador do LDAP, cadastrar um grupo ou usuário e interagir com o diretório LDAP (Figura 34). Figura 34. Caso de Uso do Modelo de Negócio

62 62 O modelo de classes são as apresentações das classes, juntamente com os relacionamentos dos atributos e o campo id_ldap que guardará a identificação que representa o usuário após a autenticação no diretório LDAP (Figura 35). Figura 35. Diagrama de Classes Beans e LDAP

63 63 O levantamento dos dados foi realizado com a criação de cinco tabelas, que são elas: usuários, grupos, grupos/usuários, eventos e permissões, nas quais foram apresentadas na Figura 35. A identificação das permissões após a autenticação será comparada com o atributo chamado id_ldap da tabela de usuários, a fim de verificar as permissões de ação aos sistemas de software. Para realizar a autenticação do usuário é necessário que o mesmo informe o login e senha e logo após o grupo que ele o pertence, já o usuário administrador do LDAP, não é necessário informar o grupo (Figura 36). Figura 36. Página de Autenticação dos Usuários para efetuar o acesso ao Aplicativo Demonstrativo Após a validação da autenticação, será verificada primeiramente, a existência do solicitante no diretório LDAP, logo em seguida, a possibilidade do mesmo ser o administrador ou o usuário que pertence às unidades organizacionais.

64 64 Ao acaso do usuário ser o administrador, o mesmo acessará todas as funcionalidades do aplicativo demonstrativo, a qual atribuirá as permissões aos grupos e usuários (Figura 37). Figura 37. Aplicativo Demonstrativo Mas, se não for o administrador, será acessado somente uma página em que terá as informações relacionadas ao usuário que autenticou no sistema (Figura 38).

65 65 Figura 38. Permissões de Ação do Usuário Simples que acessou ao Aplicativo Demonstrativo Levando em considerações a manutenção das contas dos usuários de sistemas. Após o administrador do LDAP, excluir um grupo ou um usuário será eliminado todas as informações que estão relacionadas, até então no serviço de diretórios. As demais páginas receberão os mesmos conceitos e só não irão interagir com o serviço OpenLDAP.

66 66 6 CONCLUSÕES Os conceitos retirados das pesquisas elaboradas demonstraram uma maneira eficaz de visualização das informações dos usuários (DIT). Com a unificação das contas, facilitou as manutenções dos usuários, devido os mesmos estarem centralizados, e aparentemente, separados pelas unidades organizacionais (ou), delimitando o tipo do usuário. Com as autenticações também centralizadas, facilitaram os acessos a quaisquer recursos de rede e aplicativos, que comunicam com o serviço de diretórios, a fim de utilizar, do usuário, as mesmas credenciais válidas para autenticação. A grande vantagem na utilização dessa tecnologia é por atuar diretamente na camada TCP/IP e não utilizar os poderes computacionais para validar a autenticação. Isso quer dizer, que o LDAP é uma alternativa de implementação das funcionalidades das autenticações de usuários de sistema, sem incriminar as autenticações realizadas nos bancos de dados do SGBD. Porque as pesquisas foram relacionadas somente na centralização e integração das contas dos usuários de sistemas, para a diminuição de custos nas manutenções. E os testes de autenticação foram para determinar uma possível integração dos usuários e grupos de sistemas aos serviços de diretórios. Para a instalação do sistema operacional Linux, serviço de diretórios OpenLDAP e bibliotecas de autenticação (PAM e NSS) não há custos, devido essas tecnologias serem gratuitas. A partir disso, além do LDAP proporcionar todas essas facilidades de integração, o mesmo também mostra que não há custos de implantações. Estatisticamente, os resultados obtidos na avaliação da autenticação dos usuários no diretório LDAP demonstraram-se ágil e dinâmico em realizar uma possível integração da manutenção dos usuários LDAP aos sistemas de software. Esses testes demonstraram que o LDAP, além de centralizar as informações dos usuários, ele também disponibilizar as autenticações válidas de forma rápida e concisa, devido ele autenticar cada um dos usuários em menos de um segundo. No aplicativo demonstrativo, o LDAP se apresentou ativamente compatível com linguagem Java, na qual não houve dificuldades na implementação. Para ter certeza,

67 67 se os usuários e grupos estavam sendo inseridos, ou mesmo, removidos, foram utilizados os gerenciadores de diretórios: phpldapadmin (gerenciador web) e LDAPAdmin (gerenciador Desktop), para os dados serem visualizados de forma clara e organizada. Com todas as considerações demonstradas, o LDAP abrange perspectivas de contribuições com implantações de sistemas integradas a esse serviço. Porém, o resultado obtido nessa pesquisa foi de suma importância para quem pretende migrar os sistemas e recursos de rede a serviço de diretórios, para efetuar uma única autenticação do usuário. Para as instituições que tenham sistemas diferentes oriundos de fornecedores diferentes, ao aplicar essa tecnologia, facilitará o controle de acesso a todos os serviços disponibilizados por cada instituição, através de um único domínio.

68 68 REFERÊNCIAS BIBLIOGRÁFICAS BAPTISTA, Miguel; DOMINGUES, M.. Desenvolvimentos Avançados em Redes. Lisboa: FCCN (Fundação para a Computação Científica Nacional), BARTH, Douglas Graciano, SIEWERT Vanderson Clayton. Lightweight Directory Access Protocol, Gestão da Segurança da Informação em Redes de Computadores, pp. 1-2, BRANCO, Rodrigo Rubira. Segurança da Informação, Firewalls security. Bauru: BRESSAN, Graça. Serviços de Nomes DNS, X.500 e LDAP. São Paulo: CAMPOS, Augusto. A IDE para modelagem de dados JUDE. São Paulo: Disponível em: < Acesso em: 27 Out CARTER, Gerald. LDAP System Administration. Sebastopol, CA: O Reilly and Associates, Inc, March CERQUEIRA, Alisson Gomes. Implementação de Módulos PAM e NSS para Autenticação Segura e Distribuída. Lavras: COUTINHO, Gustavo Lacerda; MSILVA, Renan Galvão. Funcionamento do TLS. Rio de Janeiro: CRUZ, Carla; RIBEIRO, Uira. Metodologia Científica Teoria e Prática, 1. ed. Belo Horizontes: Axcel Books, pp , KANIES, Luke A., Um Introdução ao LDAP. The O'Reilly Network: KELLERMANN, Gustavo Adolfo. SILVELLO, Júlio César. Introdução e Conceitos de LDAP. Porto Alegre: Disponível em: < Acesso em: 04 abr LEITE, Ricardo Baía. Fundamentos de Redes de Computadores. Disponível em: < >. Acesso em: 03 abr LUPPI, Iria. Tipos de Sistemas de Informação na empresa. Oficina da Net: Disponível em:

69 69 < >. Acessado em: 31 mar MACHADO, Erich Soares; MORIJR, Flávio da Silva. Autenticação Integrada Baseada em Serviço de Diretório LDAP. São Paulo: MACORATTI, José Carlos. Padrões de Projetos: O modelo MVC - Model View Controller. São Paulo: Disponível em: < Acesso em: 17 Out MALDANER, Giani. Revolucionando a sua empresa. Sisnema Informática Porto Alegre: Disponível em: < Acesso em: 17 mar OLIVEIRA, Marcelo Silva de. Orientações Metodológicas para Monografias de Lato Sensu. Material submetido para apreciação junto ao Conselho Editorial do DEX-UFLA visando tornar-se mais um volume da série Texto Acadêmico da Editora da UFLA. DEX- UFLA PAPOTTI, Carlos Fernando; BEVILACQUA, José Ricardo M.; MARCONDES, Julio César Costa; BALDIN, Raul. Lightweight Directory Access Protocol LDAP. Campinas: PIRES, Paula. Fundamentos de JNDI, Núcleo de Computação Eletrônica Universidade Federal do Rio de Janeiro (UFRJ). Rio de Janeiro: REINHART, Alessandro; MELLO, Daniel; MARTINS, Fabiano; MACHADO, Marcos. Gerenciamento Integrado de Identidade em Ambientes Corporativos. São Leopoldo: SEZANOWITCH, Robinson Luis, História do LDAP. Florianópolis: Disponível em: < Acesso em: 15 mai SILVA, Douglas Marcos da. UML Guia de Consulta Rápida., 3. ed. São Paulo: Novatec, SUNGAILA, Marcos. Autenticação Centralizada com Open LDAP, 1. ed. São Paulo: Novatec, TEIXEIRA, Roberto; MERCER, Carlos Daniel. Guia do Servidor. Curitiba: Conectiva S. A., 2000.

70 70 ANEXO A ALGORÍTMOS DA AVALIAÇÃO DA AUTENTICAÇÃO A apresentação dos algoritmos que fazem parte da avaliação da autenticação dos usuários no diretório LDAP. Figura 39. Algoritmo que Insere os Usuários no diretório LDAP, de acordo com a Proporção

71 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

72 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

73 Figura 42. Algoritmo que Apaga todos os Usuários do diretório LDAP, de acordo com a Proporção 73

74 74 ANEXO B RESULTADOS DOS TESTES DAS AUTENTICAÇÕES Alguns resultados obtidos pela execução de dois algoritmos (A e B) do aplicativo de avaliação da autenticação, em forma seqüencial, de até cem mil usuários, a partir de quarto tipos de conexão a Internet. Figura 43. Avaliação A da Autenticação de Mil Usuários com Conexão de Internet Dial Up

75 Figura 44. Avaliação A da Autenticação de Mil Usuários com Conexão de Internet Rede Local 75

76 Figura 45. Avaliação A da Autenticação de Cem Mil Usuários com Conexão de Internet Wireless 76

77 Figura 46. Avaliação B da Autenticação de Dez Mil Usuários com Conexão de Internet Rede Local 77