Por Luke A.
Kanies - 16/08/2001
Artigo publicado originalmente
em
http://www.oreillynet.com/pub/a/onlamp/2001/08/16/ldap.html,
na The O'Reilly
Network.
Um ano ou dois atrás, parecia que todo mundo já havia ouvido falar sobre o LDAP, e muitas poucas pessoas estavam falando sobre o mesmo, mas nenhuma parecia estar fazendo algo com o LDAP.
Parece que isto está finalmente mudando, o que é especialmente bom para administradores e desenvolvedores. O LDAP pode exercer um papel vital em redes de todos os tamanhos, mas como a maioria das novas tecnologias, ele sofre da Regra-22, ninguém está usando ele por que não é suportado e os desenvolvedores não o estão suportando por que ninguém o está usando.
Para entender por que e como o LDAP está se tornando uma ferramenta tão importante na vida de um administrador de redes, é necessário entender quais problemas o LDAP foi desenvolvido para resolver e como ele o faz. Isto significa que também é necessário entender o próprio LDAP, tanto como tecnologia quanto como ferramenta.
Devido à dificuldade em separar as atividades do administrador de sistemas das atividades do administrador de redes, e por que elas muitas vezes se sobrepõem, especialmente em pequenos ambientes, vou me referir genericamente às pessoas de ambas categorias como administradores de rede. Eu escolhi o termo "administrador de redes" como o termo genérico por que um sistema de qualidade ou administrador de redes está preocupado com a rede inteira de dispositivos e sistemas, e não em nós individuais. O termo "administrador de rede" coloca maior ênfase na visualização da rede como um todo, tornando o mesmo um termo mais apropriado.
Neste artigo introdutório, eu espero introduzir o LDAP e o conceito de diretórios online, e explicar por que você vai querer eles e o que você pode fazer com os mesmos. Em artigos posteriores, irei fornecer explicações técnicas mais profundas de como usar o LDAP, junto com algumas aplicações exemplo.
O LDAP é a última iteração de um longo processo de desenvolvimento que começou com a especificação de diretório X.500 e o correspondente Directory Access Protocol (DAP) do fim dos anos 1980 e início dos anos 1990 (para uma história mais completa do LDAP, e mais informações em geral, veja " Understanding and Deploying LDAP Directory Services", de T. Howes, M. Smith e G. Good).
O DAP era um protocolo difícil de trabalhar e implementar, e protocolos mais fáceis foram desenvolvidos com a maior parde de sua funcionalidade mas com muito menos complexidade. Eventualmente, estas versões foram avaliadas pelo IETF e o OSI-DS e foram mesclados na especificação Lightweight Directory Access Protocol, ou LDAP, primeiramente publicada como a RFC 1487 em 1993. O LDAP ganhou algum uso na versão 2, especificada na RFC 1777.
O LDAP é uma definição de protocolo para acesso a bancos de dados especializados chamados diretórios. É similar ao SQL no sentido que é uma linguagem para interagir com bancos de dados sem especificar um banco de dados particular. De fato, o banco de dados de suporte ao LDAP é quase sempre um sistema RDBMS geral, como o LDBM ou o Oracle.
O uso do LDAP para fazer a interação com o banco de dados cria algumas limitações para o banco de dados, devido às suposições que o protocolo faz e a necessidade especializada de um diretório versus um banco de dados relacional padrão. Mas estas limitações são necessárias para poder obter todas as funcionalidades desejadas de um diretório.
O uso da palavra "diretório" neste contexto pode confundir as pessoas, fazendo-as pensar que a maioria das redes atuais não usam diretórios, ou que o LDAP será o único diretório na rede. Na verdade, os diretórios são um suporte de vida, especialmente no mundo da computação. A maioria das pessãos estão familiarizadas com o processo de pegar um catálogo de telefone ou um mapa do shopping center como um diretório, mas por alguma razão insistem no uso do termo "banco de dados" na computação, mesmo quando a palavra diretório seria mais específica e correta. Como exemplo, eu chamo o sistema de registro de informação de usuários do Unix de "banco de dados passwd", mas aquele banco de dados é facilmente qualificado como diretório.
Em sua definição mais básica, um diretório é qualquer banco de dados mais especializado em leitura que escrita. O catálogo telefônico somente é distribuído uma vez por ano, o diretório do shopping center somente é alterado quando as lojas são mudadas, e o banco de dados passwd somente é atualizado quando a informação de algum usuário é alterada -- mas todas estas informações são lidas frequentemente. A definição não é mais específica que isto porque existem tantos depósitos de ifnormação que podem ser qualificados de diretórios, apesar de que, falando de modo geral, um diretório será muito mais pesquisado que navegado. A listagem que é mais frequentemente referida a um diretório na indústria técnica, um diretório de sistema de arquivos, também se encaixa nesta definição, por que um diretório é lido toda vez que um arquivo listado é acessado de alguma forma, mas somente é escrito quando os arquivos são criados ou destruídos. Além disto, diretório quase sempre é lido para uma pesquisa por um arquivo que simplesmente para navegação na lista de arquivos.
Quase todo mundo envolvido no desenvolvimento ou manutenção de aplicações ou serviços de rede está trabalhando com pelo menos um diretório: um sistema que mantém as informações do usuário. Quase todos serviços exigem algum tipo de serviço de autenticação, obrigando desta forma que aqueles serviços mantenham um diretório de usuários. Devido a isto, a forma mais comum de diretório online é de informações de usuários. Os diretórios são úteis para uma vasta gama de informações além destas. Por exemplo, sistemas Unix mantém diretórios para serviços, grupos, e muitos outros tipos de dados, o Domain Name System (DNS) é um diretório global bastante especializado para correlação nome-de-host-para-endereço, e os diretórios web usados para conjuntos de navegação de web sites estão aparecendo em todos os cantos.
Já vimos que praticamente todas as redes utilizam uma variedade de diretórios, geralmente para serviços especializados. Na linguagem dos bancos de dados, isto significa que os dados do diretórios não estão normalizados, o que significa que muitas informações são armazenadas em mais de um lugar, e que devem ser alteradas em vários locais quando uma alteração se faz necessária.
Isto é um problema por muitas razões. A mais óbvia é que toda vez que qualquer informação em qualquer destes diretórios é alterada, todos os outros diretórios devem ser encontrados para que seja feita a mesma alteração. Isto não só é difícil, é geralmente ingerenciável -- prova disto é a facilidade com que as senhas do mesmo usuário em diferentes serviços ficam fora de sincronismo.
Além disto, sempre que dois serviços implementam suas próprias versões do mesmo estilo de diretório, há uma duplicação de esforços. Não somente os desenvolvedores de cada serviço tem que desenvolver seu próprio diretório, mas os administradores de cada serviço tem que manter os diretórios separadamente -- um único usuário nos dois serviços provavelmente terá uma experiência diferente com cada serviço, e é quase impossível administrar centralizadamente estes múltiplos diretórios.
A segurança é geralmente o pior problema. Provavelmente todos os desenvolvedores e administradores estão familiarizados com as dores de cabeça associadas com a segurança do usuário. As senhas estão protegidas? O transporte é seguro? O usuário realmente provou sua identidade? Será que não deixei acidentalmente um furo que permite que alguém obtenha mais privilégios? O diretório de usuários estará sempre disponível? Quando múltiplos serviços implementam diretórios separados para a mesma informação, cada um deve cobrir de forma completa estes problemas de segurança. A estatística básica virtualmente garante que teremos mais problemas de segurança que usando um diretório unificado, e ito também significa que os serviços terão políticas de segurança diferente e possivelmente conflitantes.
O que você realmente quer em uma rede é a unificação de diretórios, e é exatamente para isto que o LDAP foi projetado. Com esta unificação, você consegue normalização de dados, administração central, experiência do usuário consistente, gerenciamento e políticas de segurança consistentes, menos problemas de segurança, e menos tempo de desenvolvimento desperdiçado.
O LDAP foi projetado especificamente para resolver os problemas causados pela proliferação de diretórios pela erde, e existem sete aspectos de sua implementação atual que lhe dão esta habilidade.
Como o LDAP foi projetado para ser um diretório de propósito geral, ele teve que ser extensível. Ele usa um esquema de definição orientado a objeto, baseado em herança, que permite fácil extensão para qualquer uso razoável. Existe um esquema básico que é parte da especificação do LDAP, e existem outros padrões de fato para vários serviços. Entretanto, espera-se que a maioria dos desenvolvedores irá extender os esquemas básicos.
Um dos mais importantes aspectos do desenvolvimentos do LDAP, e que fez com que o mesmo fosse adotado em vez do DAP, é que ele é um protocolo simples e é relativamente simples implementar e trabalhar com o mesmo. Isto fica transparenet pelo fato que o LDAP é suportado pela maior parte das linguagens de programação, incluindo C, Java e Perl, e ou é suportado ou será suportado pela maior parte dos sistemas operacionais, incluindo o Solaris, GNU/Linux, Microsoft Windows, e o Mac OS.
Com o uso de replicação de dados, é possível replicar todo ou parte de um diretório LDAP para locais separados fisicamente, o que permite que os dados tenham alta disponibilidade e coloca os mesmos tão próximos quanto necessário do cliente. Utilizando referências, domínio de dados de porções do diretório podem ser distribuídos em diferentes servidores LDAP, permitindo assim que partes de uma empresa ou projeto tenham controle sobre os dados necessários ao mesmo tempo que mantém uma única autoridade sobre cada parte dos dados.
Um grande foco do desenvolvimento do LDAP foi a segurança, com a versão 3 do protocolo LDAP trazendo significativos melhoramentos.
Existem três aspectos básicos na proteção de informação em um diretório: acesso, autenticação e autorização (AAA, ou Triplo-A). Acesso é a habilidade de conectar-se a um serviço e pode ser restringida baseado em detalhes como hora do dia ou endereço IP, autenticação é a habilidade de provar ao serviço que um cliente é um usuário válido, e autorização é o serviço fornecendo ou negando direitos específicos ou funcionalidades ao cliente.
Infelizmente, a sintaxe das ACLs ainda não é parte da especificação LDAP. Parece que a implementação da Netscape das ACLs será aceita como padrão, mas isto ainda não aconteceu e diferentes servidores LDAP implementam as ACLs de diferentes formas. Entretanto, isto não deve afetar o desenvolvimento ou funcionamento dos clientes.
Para acesso seguro, o LDAP suporta o Transport Layer Security (TLS), que criptografa toda a comunicação entre cliente e servidor. Para autenticação, o LDAP suporta a Simple Authentication and Security Layer (SASL), que permite que o cliente e servidor negociem um método de autenticação (seguro).
O TLS e o SASL provêm funcionalidades criptográficas mas não o controle sobre o acesso e autenticação. O LDAP irá fornecer a habilidade de controlar todos os três aspectos da AAA através de Access Control Lists (ACLs) (Listas de Controle de Acesso). As ACLs podem ser usadas para autorizar o acesso baseado em muitos fatores diferentes. Elas podem ser usadas para forçar tipos específicos de autenticação e, uma vez que o cliente esteja plenamente autenticado como usuário válido, as ACLs são usadas para autorizar o usuário.
Como o LDAP é um padrão aberto mantido pela IETF, ele pode ser utilizado por qualquer desenvolvedor, companhia, ou administrador sem receio de ficar aprisionado a protocolos proprietários ou a vendedores específicos, e permite que a escolha da implementação seja baseada nos detalhes do projeto em vez de preocupações de interoperabilidade. Isto também significa que o LDAP pode progredir de acordo com as necessidades das pessoas que o utilizam, em vez de uma corporação que está concentrada nos lucros ou fatia de mercado.
A especificação LDAP garante que os clientes LDAP podem solicitar a lista completa de funcionalidades de esquemas de dados de qualquer servidor LDAP, permitindo desta forma que o cliente altere sua funcionalidade de acordo com a do servidor, que deverá fornecer grande interoperabilidade entre diferentes implementações e versões do LDAP.
O LDAP utiliza o UTF-8 para representação interna de strings. Isto permite que o LDAP armazene e manipule qualquer linguagem do mundo.
Esta não é uma lista exaustiva de todas as funcionalidades do LDAP, mas detalha alguns dos mais importantes aspectos do protocolo. dE fato, uma das razões pela qual o LDAP está sendo adotado agora é apenas marginalmente relacionada ao LDAP em si: a indústria de computação, especialmente na área de administração de redes, está pronta para diretórios corporativos. Isto é evidenciado pelo fato destes estarem surgindo em todos os cantos, de servidores como o Directory Server da Netscape e o Active Directory da Microsoft a clientes como clientes de email e sistemas operacionais todos atendendo a especificações padrão como a iniciativa Directory Enabled Networks ( DEN).
Infelizmente, o LDAP não é o tipo de panacéia que todos sonham. O problema principal é que ele não é suportado como poderia ser. Por exemplo, o sistema operacional Solaris da Sun tem suporte a LDAP no seu serviço de nomes, mas este suporte não inclui qualquer tipo de criptografia, que é basicamente inaceitável. Também há um surpreendenet número de fabricantes e programas que não oferecem suporte onde este deveria haver, e muitos tomadores de decisões tecnológicas ou não sabem o que é o LDAP ou não pensa que ele importa para eles.
Isto aponta para outro problema com o estado do LDAP hoje: não há muita documentação ou suporte do tipo para leigos. Sim, você pode ler as RFCs e o código fonte, mas descrições em um nível mais elevado do que é o LDAP e como ele pode ser útil, agora e no futuro, está em falta, especificamente em formatos suscintos (o melhor livro sobre LDAP disponível hoje tem cerca de 800 páginas). mesmo para as aplicações que atualmente suportam o LDAP, é geralmente muito mais difícil fazer as mesmas funcionarem que deveria ser, o que está causando uma adoção lenta do LDAP.
Apesar de ser fácil ter uma visão pessimista do futuro do LDAP -- e certamente do seu presente -- o fato é que mais fabricantes, aplicações, linguagens e sistemas operacionais estão suportando o LDAP, e mais organizações estão ficando dependentes dele para a administração de informações-chave. Os diretórios LDAP são exelentes para organizações que tem bastanet desenvolvimento web ou desenvolvimento de aplicações customizadas. Apesar do suporte da indústria não ser o melhor agora, a maior parte dos fabricantes suportam o LDAP atualmente, quer parcialmente ou completamente, ou estão falando sobre ter este suporte. E, francamente, o LDAP é um protocolo simples e possui APIs para qualquer linguagem. Se você está desenvolvendo aplicações web, ou só precisa de um bom diretório para armazenar informações no mesmo, provavelmente você deveria dar uma olhada no LDAP -- você pode gostar do que vai encontrar.
Desta forma, agora é a hora de aprender sobre o LDAP e tentar entender qual o papel que ele pode exercer naquilo que você faz, seja sua função a de desenvolvedor, administrador, tomador de decisões, ou os três. Quanto mais demorar para que nossa indústria suporte plenamente o LDAP como um padrão para diretórios, mais tempo todos iremos gastar mantendo depósitos de informações redundantes e quase sempre inadequados, além dos métodos para interagir com os mesmos.
Na próxima vez, iremos cobrir o protocolo LDAP com mais profundidade, e começaremos a desenvolver nossa experiência com o LDAP construindo um diretório LDAP básico.
Luke A. Kanies é um administrador de sistemas Unix que está mais interessado no sistema operacional do que no que pode ser feito com o mesmo. Ele trabalha atualmente como contratante e pesquisador, tentando fazer um melhor sysadmin.
Original: oreillynet.com
Copyright © 2000 O'Reilly & Associates, Inc.
Tradução: Copyright © 2001 Cesar A. K. Grossmann