3. Sobre o LDAP - Coordenação de Projetos

Propaganda
UNIVERSIDADE FEDERAL DE SANTA CATARINA – UFSC
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA – INE
CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO – SIN
Interface de Administração de Diretórios
Estudo de caso OpenLDAP
Autores:
Maiko Eskelsen
Francisco Alexandre Luckmann
Orientador:
Prof. Dr. Leandro José Komosinski
Membros da Banca:
Marcos Santos Zarbato
Prof. Dr. Frank Augusto Siqueira
Florianópolis, 01 de Fevereiro de 2007.
Sumário
1.
Introdução ............................................................................................................................................... 5
2.
Definição do problema a ser resolvido .................................................................................................. 6
3.
Sobre o LDAP.......................................................................................................................................... 8
4.
5.
3.1
O que é LDAP? ............................................................................................................................... 8
3.2
O Surgimento e a Evolução do LDAP ............................................................................................. 8
3.3
O que é um diretório? ..................................................................................................................... 9
3.4
O que é um Serviço de Diretórios ................................................................................................. 11
3.5
Modelos de dados do LDAP .......................................................................................................... 11
3.6
As vantagens do LDAP .................................................................................................................. 13
Análise das Ferramentas existentes ..................................................................................................... 14
4.1
PhpLDAPAdmin ............................................................................................................................ 14
4.2
LDAP Browser Editor ................................................................................................................... 16
4.3
SMBLDAP-Tools ........................................................................................................................... 18
Solução Proposta ................................................................................................................................... 21
5.1
Tecnologias Utilizadas .................................................................................................................. 21
5.1.1
Java ........................................................................................................................................... 21
5.1.2
Ferramentas de Desenvolvimento ............................................................................................. 22
6.
Metodologia e Cronograma de Atividades ......................................................................................... 23
7.
Ambiente de Desenvolvimento ............................................................................................................. 25
7.1
Sistema Operacional - Instalação e Configuração Inicial do SO OpenSUSE 10.0....................... 25
7.2
Servidor OpenLDAP...................................................................................................................... 25
7.3
Instalação e Configuração das Ferramentas de Desenvolvimento ............................................... 27
7.3.1
Instalação da Ferramenta Netbeans .......................................................................................... 27
7.3.2
Instalação da Ferramenta Macromedia Dreamweaver .............................................................. 27
7.3.3
Tomcat ...................................................................................................................................... 28
7.3.4
A Biblioteca JLDAP ................................................................................................................. 28
8.
Planejamento do Sistema ..................................................................................................................... 29
8.1
Estrutura Geral da Aplicação ....................................................................................................... 29
8.2
Casos de Uso ................................................................................................................................. 30
8.2.1
Caso de Uso – A1 (Criar Usuário) ............................................................................................ 30
8.2.2
Caso de Uso – A2 (Editar Usuário) .......................................................................................... 32
8.2.3
Caso de Uso – A3 (Apagar Usuário) ........................................................................................ 33
8.2.4
Caso de Uso – A4 (Criar Grupo) .............................................................................................. 34
8.2.5
Caso de Uso – A5 (Editar Grupos) ........................................................................................... 35
8.2.6
Caso de Uso – A6 (Trocar Senha) ............................................................................................ 36
2
8.2.7
8.2.8
8.2.9
9.
Caso de Uso – A7 (Backup) ..................................................................................................... 37
Caso de Uso – A8 (Editar Schemas disponíveis no diretório) .................................................. 38
Caso de Uso – A9 (Replicação) ................................................................................................ 39
Desenvolvimento ................................................................................................................................... 40
9.1
Atividades de inicialização do sistema .......................................................................................... 40
9.1.1
Login no Sistema ...................................................................................................................... 40
9.1.2
Adicionar Grupo ....................................................................................................................... 43
9.1.3
Adicionar Usuário..................................................................................................................... 46
9.1.4
Alterar Grupo ............................................................................................................................ 48
9.1.5
Alterar Usuário ......................................................................................................................... 51
10.
Considerações Finais ........................................................................................................................ 54
11.
Conclusão .......................................................................................................................................... 55
12.
Referências Bibliográficas ............................................................................................................... 56
Resumo
3
Este trabalho apresenta uma solução para administração de um Servidor de
Diretórios, mais especificamente o Servidor OpenLDAP.
Inicialmente faremos uma introdução aos conceitos e abordagens
relacionadas ao protocolo LDAP, bem como seu histórico de desenvolvimento, a
sua importância na administração e gerencia de redes através de um Servidor
LDAP. Posteriormente a isso, mostraremos uma análise das ferramentas
existentes para Administração de Diretórios, apontando quais suas características
e funcionalidades e, também eventuais aspectos negativos como falhas e
deficiências operacionais. Em seguida, como nossa proposta, sugestionaremos a
implementação de uma nova interface para Administração de Diretórios utilizando
o Servidor OpenLDAP. A interface que será desenvolvida tem como objetivo
desempenhar as principais e essenciais tarefas de gerenciamento do diretório
OpenLDAP.
4
1. Introdução
Num ambiente com Sistemas Operacionais heterogêneos, a necessidade de
unificar a base com as informações necessárias para autenticação e permissões
de acesso a recursos de redes é relevante, tanto para os administradores da
Rede, como para os usuários. Atendendo essas necessidades do mercado
corporativo, varias grandes empresas desenvolveram tecnologias baseadas em
diretórios que possibilitam a administração de um serviço de diretórios.
Além das implementações feitas por grandes fabricantes de software, a
Universidade de Michigan disponibilizou um servidor de diretório. Este servidor
passa por constante evolução, através da colaboração de programadores de
diversas partes do mundo. Coordenados por uma Fundação chamada OpenLDAP,
criou-se uma alternativa open source para as empresas que queiram implantar o
serviço de diretórios, o OpenLDAP.
O desenvolvimento do OpenLDAP prossegue, seguindo os padrões da IETF1
(Internet Engineering Task Force) e atualmente contempla a implementação da versão
3 do padrão do protocolo LDAP.
A grande diferença entre as soluções de diretório comercializadas pelas
empresas, está na ferramenta de administração do diretório. São ferramentas
ricas em recursos e facilitam em muito a vida dos Administradores de Redes por
estarem integradas com os diversos serviços de rede que o Sistema Operacional
oferece. No caso do OpenLDAP, há um grande número ferramentas, no entanto
não oferecem uma solução completa e integrada com o Sistema Operacional e
seus serviços de rede.
Assim, esse Trabalho de Conclusão de Curso, pretende estudar as
ferramentas disponíveis no momento para uso com o servidor de diretório
OpenLDAP, identificando pontos positivos e negativos. Concluída a fase de
análise, pretende-se criar uma ferramenta de administração que permita a
utilização do OpenLDAP como Serviço de Diretório para armazenar as
informações dos diversos serviços de redes disponíveis no Sistema Operacional
Linux. Entre as tarefas que se pretende contemplar podemos citar a configuração
do serviço de diretório, backup, replicação e principalmente, a implementação das
tarefas que envolvem o gerenciamento de contas de usuários.
O desenvolvimento da aplicação terá como base o contexto do
CIRAM/EPAGRI (Centro de Informações de Recursos Ambientais e de
Hidrometeorologia de Santa Catarina).
1
Um grupo de pessoas que tem a missão de criar soluções técnicas para a evolução da Internet.
5
2. Definição do problema a ser resolvido
Para sabermos quais são os problemas e quais as soluções às quais
atenderemos, vamos definir as tarefas mais comuns executadas por um
administrador de redes que utilize o servidor OpenLDAP.
Considerando o uso do Serviço de Diretórios, com o OpenLDAP, a grande
dificuldade na sua implantação e utilização, está no fato de não existir uma
interface de Administração amigável, com acesso via web, que satisfaça as
principais necessidades de um Administrador de Diretórios. Existem ferramentas
comerciais, bastante eficientes, mas para utilização em Diretórios também
comerciais.
A Tabela 1 mostra as atividades mais comuns de um Administrador de
Diretórios, podendo melhor a compreensão do que vem a ser a administração de
um serviço de diretório.
Com o objetivo de indexar e referenciar cada tarefa em futuras citações no
decorrer do desenvolvimento dos trabalhos foram atribuídos códigos a cada uma
das atividades.
6
Código Atividade
Descrição
Criar Usuário
Adicionar um usuário atribuindo valores obrigatórios
para uma conta de usuário num Sistema Unix e como
opcional a inclusão de atributos para viabilizar a
utilização das informações em outros Sistemas
Operacionais, por exemplo, o Sistema Operacional
Windows.
Editar Usuário
Permitir a edição dos atributos de uma entrada no
Diretório. Exemplo: editar um atributo de um usuário
com a opção de aplicar essas modificações a outros
usuários, a um determinado grupo ou a todos.
A3
Apagar Usuário
Remoção de um objeto do diretório. Exemplo:
Remoção de um usuário prevendo possibilidade de
remoção dos arquivos pertencentes a esse usuário e
demais informações do mesmo no Diretório.
A4
Criar Grupo
Criar um grupo, prevendo a possibilidade de incluir
usuários a esse grupo durante a criação do mesmo.
A5
Editar Grupos
Editar um grupo, ou seja, adicionar usuários, remover
usuários, alterar o nome do grupo.
A6
Troca de Senha
Permitir para o Administrador do Diretório a troca da
senha de qualquer usuário cadastrado no Diretório.
A7
Backup
Permitir a exportação e importação do conteúdo do
diretório em formato padrão (LDIF).
A8
Editar Schemas
disponíveis no
diretório
Permitir a adição de novos esquemas no diretório,
viabilizando assim a adição de novos atributos.
Replicação
Permitir a configuração de um ambiente replicado, ou
seja, utilizando os componentes disponíveis no
OpenLDAP, gerar a configuração necessária para
que outro servidor de diretórios receba todas as
modificações feitas no servidor denominado como
principal.
A1
A2
A9
Tabela 1 – Atividades mais comuns de um Administrador de Diretórios.
7
3. Sobre o LDAP
3.1 O que é LDAP?
Segundo Howes, Smitt e Godd (1998), o LDAP (Lighweight Directory Access
Protocol) é um serviço de diretório derivado do X.5002 e padronizado pela IETF.
Um serviço de diretório mantém uma base de dados global com informações
sobre objetos, fornecendo interfaces para busca, inserção, remoção e atualização
dessas informações. O LDAP tem um conjunto de facilidades de busca bastante
rico, que permite realizar buscas complexas em todo o diretório ou em partes dele.
Possui mecanismos de autenticação, garantindo a segurança das informações no
diretório através de controles de acesso, e oferece API padronizadas e bem
documentadas.
3.2 O Surgimento e a Evolução do LDAP
No início da década de 80, quando a ISSO e o CCITT trabalhavam
conjuntamente na definição de uma padronização de um serviço de tratamento de
mensagens (a série X.4000), ficou clara a necessidade de um esfoeço paralelo
para se desenvolver um serviço de diretório que permitisse tratar melhor aspectos
de denominação (naming) e de endereçamebto.
Os trabalhos dos grupos técnicos constituídos pela ISSO e pelo CCITT
culminaram com a publicação, em 1988, de um conjunto de oito recomendações
da série X.500 (CCITT) e de normas ISSO 9594. Essas recomendações e normas
tentaram abranger o espectro de possibilidades de ambientes distribuídos em
geral, sem ficar restritas ao caso específico do serviço de tratamento de
mensagens que as motivou. O resultado foi um serviço de diretório bastante
complexo e de custo computacional incompatível com equipamentos menores. Era
muito difícil rodar clientes X.500 nos microcomputadores disponíveis na época.
O LDAP, como o nome sugere, foi originalmente desenvolvido como um front
end de menor custo computacional que o DAP do X.500. Seus antecessores
foram os protocolos DIXIE3 e Directory Assistence Service – DAS4, que já
Recomendação publicada pela organização internacional de padrões ITU-T (antiga CCITT), que
define os protocolos para sistemas cliente/servidor que mantêm e acessam diretórios de usuários e
recursos.
3 O protocolo DIXIE foi projetado para ser usado em equipamentos pequenos(exemplo, PCs e
Macintoshes) e sem potência computacional ou software necessário para implantar a pilha
completa de protocolos OSI. Esse protocolo pode também ser usado por aplicações Internet que
precisam de uma interface X.500,com um investimento muito pequeno em código.
4
Mecanismo pelo qual uma aplicação usuária poderá ter acesso ao X.500 através de um protocolo
como o DAP, porém utilizando uma conexão TCP/IP.
2
8
rodavam sobre TCP/IP e não sobre pilha OSI. Através do DIXIE ou do DAS, os
clientes se comunicavam com um servidor gateway, que traduzia as solicitações
recebidas via TCP/IP para correspondentes operações X.500 e as enviava para
um DAS, via protocolo DAP sobre a pilha OSI.
Em 1992, o grupo de trabalho OSI Directory Services (OSI-DS) de IETF
partiu das especificações do DIXIE e do DAS e definiu um protocolo de acesso
que funcionava com todas as versões de X.500. Isso resultou no LDAP, que em
1993 foi apresentado como proposta de padrão Internet e em 1995 ganhou o
status de draft standard. Boa parte desse trabalho foi realizado na Universidade de
Michigan, à qual estavam vinculados vários membros do grupo OSI-DS. A primeira
implementação do LDAP foi a da Universidade de Michigan.
A falta de suporta para o X.500 e para a pilha de protocolos OSI levou os
pesquisadores e desenvolvedores da Universidade de Michigan a criarem um
servidor LDAP standalone, o slapd. Esse grupo disponibilizou os fontes do slapd
na Internet e criou listas de usuários para divulgar e aperfeiçoar o novo serviço. O
desenvolvimento foi acompanhado por usuários e desenvolvedores do mundo
inteiro. Com a popularização do slapd, o LDAP deixou de ser uma mera alternativa
ao DAPdo X.500 e ganhou o status de serviço de diretório completo, passando a
competir com o X.500. Em dezembro de 1997, a IETF aprovou a versão 3 do
LDAP como proposta de padrão Internet para serviços de diretório.
Atualmente váriasempresas oferecem produtos LDAP, incluindo Microsoft,
Netscape e Novell. A OpenLDAP Foundation, baseada na Universidade de
Michigan, que inclui os seguintes módulos:

slapd – servidor LDAP standalone;

slurpd – servidor de replicação LDAP standalone;

bibliotecas que implemetam o protocolo LDAP;

utilitários, ferramentas e exemplos de clientes LDAP.
O desenvolvimento do OpenLDAP prossegue, acompanhando a evolução
dos padrões da IETF. Recentemente foi disponibilizado o release 2.0.7 do
OpenLDAP completando a versão 3 do padrão LDAP e algumas facilidades
adicionais.
3.3 O que é um diretório?
O verbete diretório na literatura especializada tem vários significados,
dependendo do contexto. No contexto de sistemas de arquivos ele possui um
9
significado, no contexto de redes e ambientes distribuídos outro e no contexto de
banco de dados um terceiro significado. Esses significados não são excludentes.
Vamos considerar inicialmente o significado elementar de diretório que é
lista. Lista nada mais é do que um depósito de informações. Desta forma fica mais
fácil entender porque diretório é usado nesses contextos.
No contexto sistema de arquivos nada mais é do que um arquivo especial
que contem a lista dos arquivos pertencentes a esse diretório.
No contexto de redes e ambientes distribuídos, diretório é uma lista que
contem informações, quase todos os serviços de rede, por exemplo, exigem algum
tipo de autenticação, obrigando desta forma que os serviços mantêm um diretório
de usuários (uma lista de usuários).
Já no contexto de banco de dados é muito natural já que lista é na verdade
um depósito de informações.
Quando se fala em diretório a grande maioria dos profissionais de informática
associa ao contexto de sistema de arquivos, considerando erroneamente LDAP
como sendo um.
Um diretório pode ser definido como uma base de dados global, que pode
estar fisicamente distribuída, mas mantém uma centralização lógica, cujo objetivo
é armazenar e fornecer informações sobre objetos. Esses objetos podem ser
pessoas, equipamentos, listas de distribuição, endereços de rede, endereços de
aplicações, organizações, endereços de correios eletrônicos, etc.
Exemplos de diretórios:

Guia telefônico

Guia de TV

Livro de endereços

DNS5 (Domain Name System)

NIS6 (Network Information Service)
DNS ou Domain Name System, consiste num serviço, onde são armazenadas ligações entre
endereço IPs e domínios. Quando se pede ao seu navegador, cliente de email, cliente de ftp, ou
qualquer outro aplicativo para chamar um determinado domínio, automaticamente ele ascende ao
servidor DNS configurado, e encontra o respectivo endereço IP da máquina que fornece o serviço
requisitado e, assim, torna-se possível utilizar determinados serviços usando nomes em oposição a
endereços IP.
6 NIS é um sistema distribuído de bases de dados que troca cópias de arquivos de configuração
unindo a conveniência da replicação à facilidade de gerência centralizada. Servidores NIS
gerenciam as cópias de arquivos de bases de dados, e clientes NIS requerem informação dos
servidores ao invés de usar suas cópias locais destes arquivos.
5
10

Catálogo de endereços dos clientes de e-mail

Arquivos que contenham informações das contas de usuários em um
sistema UNIX
Com isso pode-se concluir que os diretórios são comuns e nada mais são do
que um depósito de dados que é mais lido do que escrito.
3.4 O que é um Serviço de Diretórios
Trata-se de uma implementação cliente / servidor para o conceito de
diretório.
Segundo Howes, Smitt e Godd (1998), o serviço de diretórios é uma base de
dados especializada, com o propósito de prover o acesso rápido aos dados de
maneira padronizada.
Essa base tem o objetivo de organizar e facilitar eventuais alterações e
inclusões de dados de configuração nas contas individuais, ou em grupos, dos
usuários de uma determinada rede.
3.5 Modelos de dados do LDAP
No LDAP a maioria dos elementos de dados são representados como
cadeias de caracteres, processadas bem mais facilmente que dados na
representação estruturada ASN.1 usada pelo X.500. Sendo, os dados codificados
para transporte em redes usando uma versão simplificada das mesmas regras de
codificação usadas pelo X.500.
Do ponto de vista conceitual, o serviço de diretório LDAP é composto pelos
elementos/modelos abaixo:
Modelo de informação – Todos os dados no diretório são armazenados em
“entradas”, sendo que cada entrada pertence pelo menos a uma “object
class”. Cada entrada tem uma coleção de atributos, que de fato mantém as
informações da entrada. As object classes a que uma entrda pertence
definem os atributos que ela pode ou deve conter. Esse modelo, herdado
quase sem alterações do X.55, é extensível: definindo-se novas object
classes, pode-se adicionar ao diretório qualquer tipo de informação.
11
Modelo de nomes – Especifica como a informação é organizada e
referenciada num diretório LDAP. Os nomes LDAP são hierárquicos. Nomes
são seqüências de atributos de entradas. Uma entrada raiz tipicamente
representa o nome do domínio, da companhia, do estado ou da organização.
Entradas para subdomínios, escritórios ou departamentos vem a seguir,
muitas vezes seguidas por entradas para indivíduos. Assim como o modelo
de informação, o modelo de nomes deriva diretamente do X.500.
Diferentemente do X.500, o LDAP não restringe o formato do espaço de
nomes, permitindo uma variedade de esquemas flexíveis.
Modelo funcional – Define como clientes podem acessar, manipular e
alterar as informações num diretório. O LDAP oferece nove operações
básicas: adicionar, apagar, modificar, associar (bind), dissociar (unbind),
buscar, comparar, renomear e abandonar.
Modelo de segurança – Define como a informação num diretório LDAP é
protegida contra acessos não autorizados. Um sistema de autenticação
extensível permite que clientes e servidores autentiquem suas identidades
uns aos outros. Confidencialidade e integridade podem também ser
implementadas.
Esquema LDAP – Define que dados pode, ser armazenados num dado
servidor e como esses dados se relacionam com objetos do mundo real. O
esquema pode usar object classes padronizadas, como as definidas para
países, organizações, grupos e pessoas, ou pode usar novas object classes,
criada para atender requisitos específicos de uma instalação.
Protocolo LDAP – Especifica as interações entre clientes e servidores e
define os formatos das mensagens de requisição e de resposta.
Interface de Programação – API que oferece um conjunto de funções e
definições padronizadas e é usada pelos programadores que acessam o
diretório.
Formato de Troca de Dados – O LDAP Data Interchange Format (LDIF) é
um formato textual para representação de entradas e de alterações nessas
entradas. Este Formato facilita a importação/exportação de dados de/para
diretórios X.500 ou diretórios proprietários.
12
3.6 As vantagens do LDAP
O crescimento gigantesco das redes e usuários dos últimos anos conduziu
ao fato que há diferentes redes, diferentes sistemas operacionais e diferentes
aplicações. Levando em conta a implantação de uma política de segurança, é
necessário fazer a autenticação dos usuários para que se controle o acesso aos
recursos da rede. Para todos os casos é necessário listas especializadas com
informações para autenticação e pela arquitetura das aplicações, sistemas
operacionais, essas listas mantêm informação redundante, ou seja, para cada
aplicação, cada sistema operacional diferente é necessário a manutenção das
informações.
Citamos como exemplo o servidor web apache que tem a capacidade de
autenticação, portanto necessita de alguma forma de armazenamento para
usuário. O apache utiliza uma série de programas (htpasswd, htdigest) e arquivos
(htaccess) para armazenar, adicionar e alterar a sua base de dados de usuários e
que não passa de um diretório. Já o servidor de arquivos Samba usa outro
diretório para armazenar dados sobre usuários. Além de usar outra série de
programas (smbpasswd, smbadduser) para a manutenção dessa base de dados
(diretório). Podemos citar também aplicações clientes como o Outlook que se
utiliza das informações contidas num diretório para validar usuário e senha e
posteriormente fazer o download das mensagens.
Não é necessário muito esforço para perceber as dificuldades de se manter
em vários locais as informações necessárias para validação de um usuário. Cada
aplicação que se queira disponibilizar ao usuário será necessário criar um diretório
para armazenar as informações necessárias para autenticação e controle de
acesso.
Diante desse cenário é que percebe-se a necessidade de serviço de
diretórios que possa servir a todas as aplicações, sejam elas servidoras ou
clientes. E a solução é o LDAP. O LDAP é capaz de unificar diferentes diretórios
em um único diretório. As grandes empresas de software perceberam isso e
apostaram nessa tecnologia. A Microsoft criou o Active Directory, a Novell o
eDirectory, a SUN Microsystems o iPlanet.
13
4. Análise das Ferramentas existentes
Uma vez estabelecido o que compreende a administração básica de uma
serviço de diretório, será feita uma analise das ferramentas existentes que se
propõe a administrar o Servidor de Diretórios OpenLDAP. Serão analisadas, a
princípio três ferramentas de administração de Diretórios: ‘PhpLDAPAdmin’, ‘LDAP
Browser Editor’ e ‘SMBLDAP-Tools’.
4.1 PhpLDAPAdmin
Entre as ferramentas mais populares, a ferramenta PhpLDAPAdmin
[PHPLDAPADMIN] é uma das mais utilizadas, entre os recursos que atraem é sua
interface web. Na Tabela 2 podemos verificar a relação da ferramenta
PhpLDAPAdmin com as atividades comuns ao Administrador de Diretórios.
A ferramenta PhpLDAPAdmin é uma das mais ricas em recursos atualmente
que está disponível como software livre. Entre os recursos que facilitariam a
administração podemos citar:
Uma opção que permita aplicar uma alteração para um grupo de usuários ou
para todos os usuários.
A configuração de novos schemas no Servidor OpenLDAP.
A inclusão de novos atributos de forma mais simples, ou seja, que abstraia a
complexidade através de “templates” por exemplo.
14
Atividade
Realização
Observações
A1
Sim
Contempla criação de usuário, no entanto exige o
conhecimento avançado para adicionar novos
atributos dando ao usuário a possibilidade de
autenticar em outros sistemas que não o Unix.
A2
Sim
Permite
modificar
configurados.
Sim
Exige a seleção do usuário e um clique apenas. Não
exclui os arquivos do usuário no Sistema
Operacional
A4
Sim
Permite criar grupo de vários serviços, mas é
necessário criar um tipo e depois editar esse grupo
adicionando novos atributos exigindo conhecimento
avançado do diretório e do schema.
A5
Sim
Permite
modificar
configurados.
A6
Sim
Permite a troca através da edição do atributo de
senha do usuário.
A7
Sim
Permite exportar toda a base de dados do diretório
para um arquivo padrão ldif.
A8
Não
Não possibilita a adição de schemas novos no
servidor OpenLDAP.
A9
Não
Não disponibiliza uma interface para configurar a
replicação da base de dados com outro servidor
OpenLDAP.
A3
facilmente
facilmente
atributos
atributos
já
já
Tabela 2 – PhpLDAPAdmin em relação às atividades comuns ao Administrador de Diretórios.
15
Figura 1 - Imagem capturada da interface do phpLDAPAdmin – Adição de usuário
4.2 LDAP Browser Editor
Outra ferramenta que é amplamente utilizada é o LDAP Browser Editor
Possui um applet que permite acesso via web. A Tabela 3 mostra a
relação do LDAP Browser Editor com as atividades.
[LDAPBE].
A principal dificuldade no uso do LDAP Browser Editor consiste em não
permitir a criação de novos atributos, de forma intuitiva. Exige algumas manobras
como clonar um objeto no diretório e posteriormente editá-lo com valores
diferentes. Além de ser um processo difícil, permite dados inconsistentes no
diretório.
16
Atividade
Realização
Observações
A1
Sim
A criação de um usuário se da através da cópia de
um usuário já existente e posterior edição dos
atributos da cópia.
A2
Sim
Permite editar facilmente um usuário.
Sim
Permite deletar os atributos do usuário selecionando
o usuário e no menu de opções do botão direito do
mouse com a opção excluir.
A4
Sim
Assim como a criação de um usuário, um grupo
precisa existir no diretório para permitir a cópia e
posterior edição da cópia.
A5
Sim
Permite editar facilmente um grupo.
A6
Sim
Permite a troca e a validação antes de salvar no
diretório.
A7
Sim
Possui recurso para exportar os dados para um
arquivo ldif.
A8
Não
Não contempla
A9
Não
Não contempla
A3
Tabela 3 – LDAP Browser Editor em relação às atividades comuns ao Administrador de Diretórios.
17
Figura 2 - Imagem capturada do LDAP Browser Editor.
4.3 SMBLDAP-Tools
De acordo com definições encontradas nos documentos referentes à
ferramenta, SMBLDAP-Tools é um conjunto de scripts desenhados para ajudar a
integrar o Samba e um diretório LDAP. Eles visam tanto usuários quanto
administradores de sistemas Linux. Usuários podem mudar suas senhas de um
modo semelhante ao comando padrão "passwd''. Os administradores podem
realizar o gerenciamento de usuários e grupos via linha de comando e sincronizar
contas do Samba consistentemente [SMBLDAP]. Na Tabela 4 está a relação de
atividades mais comuns de um Administrador de Diretórios contemplada pelo
SMBLDAP-TOOLS.
O SMBLDAP-Tools se propõe a manipulação de atributos no diretório que
dizem respeito a contas padrão Linux e ao Servidor de Arquivos Samba. Apesar
dessas restrições, é uma das ferramentas mais utilizadas, pois funciona muito
bem naquilo que se propõe. Além disso, não contempla uma interface Web.
18
Atividade
Realização
Observações
A1
Sim
Contempla, mas não edita atributos diferentes
dos necessários para conta padrão Linux e do
Servidor de arquivos.
A2
Sim
Contempla
A3
Sim
Contempla, permitindo apagar os arquivos do
usuário.
A4
Sim
Contempla
A5
Sim
Contempla
A6
Sim
Contempla, permitindo ao usuário a troca da
sua senha eliminando a necessidade do
administrador para tal tarefa.
A7
Não
Não possui recurso.
A8
Não
Não possui recurso
Não
Não possui recurso, no entanto pode ser
configurado para utilizar um servidor de backup
para continuar permitindo a edição do diretório,
ou seja, ao tentar conectar no servidor principal
sem sucesso, conecta no servidor de backup,
dando assim a possibilidade de adição, edição
de atributos no diretório.
A9
Tabela 4 – SMBLDAP-Tools em relação às atividades comuns ao Administrador de Diretórios.
19
Figura 3 - Imagem capturada do comando do smbldap-tools que vai criar as entradas iniciais no
diretório para permitir a administração posteriormente.
20
5. Solução Proposta
Com base na definição do problema, no estudo das ferramentas disponíveis
e, visto seu grande número de deficiências, propomos como solução, a
implementação de uma nova ferramenta de administração de diretórios, utilizando
a tecnologia Java, permitindo acesso através de um browser de internet, ou seja,
uma aplicação com interface Web.
A solução prevê a implementação de 100% das atividades apontadas no
capítulo 2. Ou seja, executar todas as atividades essenciais da administração de
diretórios com o servidor OpenLDAP. Onde criaremos uma solução que atenda as
necessidades dos administradores de rede quanto à gerência de diretórios,
suprindo as dificuldades apresentadas pelas ferramentas analisadas.
5.1 Tecnologias Utilizadas
5.1.1 Java
Como tecnologias de implementação, utilizaremos as ferramentas, propostas
e soluções apresentadas pela plataforma Java. A plataforma Java apresenta bons
aspectos e funcionalidades voltadas para o desenvolvimento de aplicações Web.
Utilizaremos uma forma estrutural dinâmica composta por três camadas de
classes Java:
JavaBeans   Servlets   JSPs
5.1.1.1 JavaBeans
As classes JavaBeans são componentes de software projetados para serem
unidades reutilizáveis, que uma vez criados podem ser reusados sem modificação
de código, e em qualquer propósito de aplicação, seja um applet, um Servlet ou
qualquer outra. Um modelo de componente é definido como um conjunto de
classes e interfaces na forma de pacotes Java que deve ser usado em uma forma
particular para isolar e encapsular um conjunto de funcionalidades. Os
componentes JavaBeans são também conhecidos como Beans (referência).
21
5.1.1.2 Servlets
Os Servlets Java são programas que estendem a funcionalidade de um web
server, gerando conteúdo dinâmico e interagindo com os clientes, utilizando o
modelo request/response. Os servlets não são restritos ao modelo HTTP de
request/response, onde na realidade são pequenas aplicações de servidores, mas
o modelo HTTP é o modelo mais comumente utilizado (referência).
5.1.1.3 JSP
JSP (Java Server Pages) é uma tecnologia para desenvolvimento de
aplicações WEB semelhante ao Microsoft ASP7, porém tem a vantagem da
portabilidade de plataforma podendo ser executado em outros Sistemas
Operacionais além dos da Microsoft. Ela permite ao desenvolvedor de sites
produzir aplicações que permitam o acesso a banco de dados, o acesso a
arquivos-texto, a captação de informações a partir de formulários, a captação de
informações sobre o visitante e sobre o servidor, o uso de variáveis e loops entre
outras coisas (referência).
5.1.1.4 UML
UML (Unified Modeling Language) é o esquema de representeção gráfica
mais utilizado para modelagem de sistemas orientados a objetos. A UML possui
entre suas principais características, a flexibilidade, sendo também extensível e
independente de Processos de Análise e Projetos Orientados a Objetos (OOAD).
Além disso, a UML é uma linguagem gráfica complexa e repleta de recursos.
5.1.2 Ferramentas de Desenvolvimento
Inicialmente, o ambiente de implementação da tecnologia Java, a ser
utilizada, será a ferramenta NetBeans. Essa ferramenta foi escolhida pela
familiaridade que os desenvolvedores possuem com essa ferramenta, visto que já
foi bastante utilizada em nossa vida acadêmica. Juntamente com o NetBeans,
será utilizado o software de desenvolvimento web Macromedia Dreamweaver, que
será utilizado para uma melhor criação e desenvolvimento visual das páginas JSP.
7
ASP - Active Server Pages. Active Server Pages são páginas web que possuem conteúdo dinâmico. Contêm
combinações de Server-Side scripts e tags HTML. ASP roda no servidor IIS (Microsoft Information Server).
22
6. Metodologia e Cronograma de Atividades
Baseando-se na metodologia UML, e de acordo com os padrões citados por
Craig Larman [LARMAN2000] o processo de desenvolvimento de um software
está baseado em três principais etapas:
Análise – Investigação do problema;
Projeto – Solução lógica;
Construção – Implementação do código.
Com base nestes conceitos, podemos definir como principais requisitos e
casos de uso as atividades mais comuns de um Administrador de Diretórios às
quais já foram citadas.
O cronograma das atividades a serem feitas no projeto e desenvolvimento
deste projeto, foi feito baseado inicialmente no calendário escolar da Universidade
Federal de Santa Catarina e, no calendário especificado pelo professor
responsável pelas disciplinas de Projetos.
A concepção do sistema será feita baseando-se nos conceitos de
desenvolvimento citados. Tendo como divisores de etapas os casos de usos
definidos (atividades). Portanto na implementação de cada caso serão feitos os
levantamentos de requisitos e diagramas correspondentes a cada caso específico.
Portanto, ao que podemos compreender, o cronograma completo e
específico deve ser criado e dividido com base nas atividades mais comuns de um
Administrador de Diretórios.
23
Atividades
Período de Tempo Estimado
A1
2 semanas
A2
2 semanas
A3
2 semanas
A4
2 semanas
A5
2 semanas
A6
1 semanas
A7
1 semanas
A8
2 semanas
A9
2 semanas
TOTAL
16 semanas = 4 meses (aproximadamente)
Tabela 5 - cronograma de tempo baseado nos casos de uso.
24
7. Ambiente de Desenvolvimento
7.1 Sistema Operacional - Instalação e Configuração Inicial do
SO OpenSUSE 10.0
Neste arquivo descrevemos sobre os passos para se instalar o Sistema
Operacional OpenSUSE 10.0 que oferece todos os serviços necessários para o
desenvolvimento da ferramenta de administração de diretórios.
Serão usados os seguintes softwares:

Servidor Web: Apache 2.0.x

Servidor de Email: Postfix

Servidor DNS: BIND9

Servidor FTP: proftpd

POP3/IMAP: Courier-POP3/Courier-IMAP.

Servidor LDAP: OpenLDAP.
Como os passos da Instalação do Sistema Operacional Linux OpenSUSE
10.0 não fazem parte do escopo principal deste projeto, estes serão citados e
demonstrados na seção referente aos anexos.
7.2 Servidor OpenLDAP
Para viabilizar o desenvolvimento de uma aplicação que manipule os dados
do Servidor OpenLDAP, será feita uma instalação e posteriormente sua
configuração.
A instalação do OpenLDAP pode ser feita a partir dos pacotes da sua
distribuição
preferida (no caso usaremos o Sistema Operacional SuSE Linux 10.0) ou através
da compilação dos fontes. Os seguintes pacotes serão utilizados:
openldap2-2.2.27-6.i586.rpm
openldap2-back-ldap-2.2.27-6.i586.rpm
openldap2-back-meta-2.2.27-6.i586.rpm
openldap2-back-monitor-2.2.27-6.i586.rpm
25
openldap2-back-perl-2.2.27-6.i586.rpm
openldap2-client-2.2.27-6.i586.rpm
openldap2-devel-2.2.27-6.i586.rpm
Com esse conjunto de pacotes de software tem-se um Servidor LDAP,
aplicativos clientes e um conjunto de bibliotecas de desenvolvimento.
A configuração do servidor LDAP é feita através da edição do arquivo slapd.conf
que localiza-se no seguinte diretório:
/etc/openldap
É necessário definir um conjunto de parâmetros para que o OpenLDAP
esteja apto a funcionar. A configuração utilizada segue como anexo 1.
Em seguida, com o servidor OpenLDAP instalado, é necessário configurar e
localizar a base de dados LDAP e o domínio da rede [Figura 4].
Figura 4 – localização da base de dados LDAP e do domínio da rede.
26
7.3 Instalação
e
Configuração
Desenvolvimento
das
Ferramentas
de
7.3.1 Instalação da Ferramenta Netbeans
Como já foi descrito anteriormente, como ambiente de desenvolvimento,
usaremos a ferramenta NetBeans. O Netbeans é um projeto open source de
sucesso, com uma grande base de usuários, uma crescente comunidade e
parceiros mundiais. A Sun Microsystems fundou o projeto NetBeans em Junho de
2000 e continua sendo seu principal patrocinador.
A instalação do Netbeans deve seguir os seguintes passos:
 Após o download ser concluído, abra um novo terminal no Linux e vá até
o diretório onde foi salvo o netbeans (jdk-1_5_0_03-nb-4_1-linux.bin).
 Agora, utilize o comando SU para se tornar o super usuário.
 Digite o seguinte comando:
# ./jdk-1_5_0_01-nb-4_0-bin-linux.bin
 Neste momento você já poderá aconpanhar o processo inicial de
instalação. Você terá a seguinte resposta no terminal:
InstallShield Wizard…
Inicializando InstallShield Wizard...
Preparando Java(tm) Virtual Machine...
Os passos para a instalação do Netbeans podem ser acompanhados na
seqüência de passos descritos nos arquivos de anexo deste projeto.
7.3.2 Instalação da Ferramenta Macromedia Dreamweaver
Dreamweaver é um editor visual profissional que cria e gerencia sites e
páginas da web. Com o Dreamweaver é fácil criar e editar páginas compatíveis
com diversos navegadores e plataformas. O Dreamweaver oferece ferramentas
avançadas de desenho e layout, bem como facilita a utilização dos recursos do
HTML dinâmico (javascript) e códigos de linguagens para internet (Jsp, Asp,
Php,...), como os comportamentos e camadas animadas, sem gravar uma linha de
código. O Dreamweaver pode ser definido para limpar e reformatar páginas web
quando você quiser. Podendo ter suas ferramentas internas dispostas de forma
personalizada pelo programador.
A instalação do Macromedia Dreamweaver é feita de forma simples.
Através Ido uso de CD de instalação Dreamweaver deve-se executar o arquivo
27
instalador “setup.exe” que encontrasse no CD. As instruções a seguir são simples
de serem seguidas e cumpridas até a finalização da instalação. Se for solicitado, o
computador deve ser reiniciado para a finalização das configurações. A ferramenta
Macromedia Dreamweaver é executada nos sistemas operacionais Windows 95,
Windows 98, Windows NT versão 4.0, Windows 2000, Windows XP ou mais
avançados.
7.3.3 Tomcat
O Tomcat é um servidor de aplicações Java para web. É software livre e de
código aberto surgido dentro do conceituado projeto Apache Jakarta e oficialmente
endossado pela Sun como a Implementação de Referência (RI) para as
tecnologias Java Servlet e JavaServer Pages (JSP). Atualmente, o Tomcat tem
seu próprio projeto dentro da Apache Software Foundation. O Tomcat é robusto e
eficiente o suficiente para ser utilizado mesmo em um ambiente de produção.
Tecnicamente, o Tomcat é um Container Web, parte da plataforma
corporativa Java Enterprise Edition (J2EE ou Java EE) que abrange as tecnologias
Servlet e JSP, incluindo tecnologias de apoio relacionadas como Realms e
segurança, JNDI Resources e JDBC DataSources. O Tomcat tem a capacidade de
atuar também como servidor web/HTTP, ou pode funcionar integrado a um
servidor web dedicado como o Apache httpd ou o Microsoft IIS.
O Tomcat porém não implementa um container EJB. Para aplicações JEE
que utilizam Enterprise JavaBeans (EJB), você deve procurar um servidor de
aplicações JEE completo, como JBoss AS, IBM WebSphere, BEA WebLogic,
Oracle AS, GlassFish, ou o J2EE SDK incluindo Sun Java System Application
Server Platform Edition, implementação de referência para a plataforma J2EE
completa (Web e EJB), entre outros.
O Tomcat será usado para o desenvolvimento da aplicação por atender as
necessidades do projeto. Como pode ser visto na arquitetura da aplicação na
figura – Arquitetura da Solução, não será considerado o uso de EJB.
7.3.4 A Biblioteca JLDAP
A biblioteca JLDAP é um conjunto de classes que facilitam a criação de
aplicativos para acesso e manipulação de dados numa base LDAP. Ele oferece
uma vasta API que pode ser usada para operações como autenticação no
diretório, configuração, manipulação de atributos no diretório. O JLDAP é
compatível com a versão 3 do protocolo LDAP.
A documentação das classes está disponível no seguinte endereço
http://developer.novell.com/documentation/jldap/jldapenu/ietfapi/index.html
28
8. Planejamento do Sistema
8.1 Estrutura Geral da Aplicação
A estrutura geral da aplicação possuirá os seguintes componentes:

Browser Web – Programas como: Internet Explorer, Mozila, Netscape,...,
que são basicamente leitores de código HTML servindo para viabilizar o
acesso e navegação na Internet/Intranet.

JSF (Java Server Faces) - É uma tecnologia que incorpora características
de um framework MVC para WEB e de um modelo de interfaces gráficas
baseado em eventos. Por basear-se no padrão de projeto MVC8, uma de
suas melhores vantagens é a clara separação entre a visualização e regras
de negócio (modelo).

Páginas JSP – Páginas dinâmicas contendo código Java as quais serão
lidas e interpretadas pelo Browser servindo de interface entre a Aplicação e
o Usuário. De acordo com a arquitetura MVC, as página JSPs conterão
TAGs de acessos aos recursos da tecnologia JSF.

JavaBean – Classes Java que interagem diretamente com o banco de
Dados OpenLDAP.

Banco de Dados OpenLDAP – Base de Dados LDAP contendo as
informações da rede, bem como: grupos, permissões, usuários,...
Os elementos descritos acima podem ser vistos na figura abaixo [Figura 6],
bem como seu nível de comunicação e acesso entre si.
8
O objetivo do padrão MVC é dividir uma aplicação em três camadas: modelo, visualização e controle. O
modelo é responsável por representar os objetos de negócio, manter o estado da aplicação e fornecer ao
controlador o acesso aos dados. A visualização representa a interface com o usuário, sendo responsável por
definir a forma como os dados serão apresentados e encaminhar as ações dos usuários para o controlador. Já a
camada de controle é responsável por fazer a ligação entre o modelo e a visualização, além de interpretar as
ações do usuário e as traduzir para uma operação sobre o modelo, onde são realizadas mudanças e, então,
gerar uma visualização apropriada.
29
Figura 6 – Arquitetura da Solução
8.2 Casos de Uso
De acordo com a estrutura definida anteriormente e, também, com base nas
atividades tidas anteriormente neste documento como sendo as mais comuns de
um Administrador de Diretórios, definimos, para cada uma, um caso de uso
específico para que esta possa ser melhor entendida e seu(s) fluxo(s) de
execução seja visualizado.
8.2.1 Caso de Uso – A1 (Criar Usuário)
Nome
Criar Usuário
Objetivo
Cadastrar o usuário no sistema
Descrição
O Administrador da Rede cadastra o usuário no sistema
Atores
Administrador da Rede - É o operador do sistema;
Usuário - Usuário da Rede.
30
8.2.1.1 Fluxo Expandido
Descrição
O usuário chega a empresa e precisa de acesso ao
computador e aos da recursos da rede. A criação da
conta no sistema é solicitada ao Administrador da Rede.
Fluxo típico
O usuário começa a trabalhar na empresa e solicita uma
conta.
O Administrador solicita dados como nome, sobrenome
e departamento em que vai trabalhar ao usuário.
O usuário fornece os dados ao Administrador da Rede.
O Administrador abre o sistema e preenche os campos
necessários a criação de uma conta no sistema.
O Sistema solicita ao usuário que o mesmo digite uma
senha com 6 caracteres no mínimo. Após a digitação da
senha o sistema emite uma mensagem informando que
a conta foi criada.
A figura abaixo [Figura 7] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A1.
Figura 7 - Esquema de interação da atividade A1.
31
8.2.2 Caso de Uso – A2 (Editar Usuário)
Nome
Editar Usuário
Objetivo
Editar conta do Usuário
Descrição
O Administrador da Rede edita os atributos da conta do
usuário no sistema
Atores
Administrador da Rede - É o operador do sistema;
Usuário - Usuário da Rede.
8.2.2.1 Fluxo Expandido
Descrição
O usuário necessita incluir ou excluir alguns atributos da
sua conta..
Fluxo típico
O usuário fazer parte de algum grupo, que sua senha
seja alterada, etc, e solicita uma alteração.
O Administrador solicita o login do usuário.
O usuário fornece os dados ao Administrador da Rede.
O Administrador faz as alterações necessárias e solicita
ao sistema que os dados sejam gravados
O sistema emite uma mensagem informando que a
conta foi salva com sucesso.
Atores:
Administrador de Rede - Operador do Sistema;
Usuário - Usuário da Rede.
A figura a seguir [Figura 8] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A2.
32
Figura 8 - Esquema de interação da atividade A2
8.2.3 Caso de Uso – A3 (Apagar Usuário)
Nome
Apagar Usuário
Objetivo
Eliminar a conta do Usuário do sistema.
Descrição
O Administrador da Rede informa qual a conta do
usuário que deve ser excluída e de onde ela deve ser
excluída.
Atores
Administrador da Rede - É o operador do sistema
Usuário - Usuário da Rede
8.2.3.1 Fluxo Expandido
Descrição
O usuário desliga-se da empresa, então seu acesso aos
recursos da rede deve ser bloqueado através da
eliminação da conta do Usuário
Fluxo típico
O usuário desliga-se da empresa.
O administrador localiza a conta do Usuário no sistema.
O sistema exibe uma mensagem pedindo a confirmação
do desligamento.
O Administrador de Rede confirma a desvinculação do
Usuário, e a conta é eliminada do sistema.
Atores:
Administrador de Rede - Operador do Sistema
Usuário - Usuário da Rede
33
A figura abaixo [Figura 9] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A3.
Figura 9 - Esquema de interação da atividade A3.
8.2.4 Caso de Uso – A4 (Criar Grupo)
Nome
Criar Grupo
Objetivo
Criar e editar um novo grupo de usuários no sistema.
Descrição
O administrador cria um novo grupo de usuários
informando também, as permissões e restrições de
acesso impostas a este novo grupo.
Atores:
Administrador da Rede - É o operador do sistema
8.2.4.1 Fluxo Expandido
Descrição
O administrador cria um novo grupo de usuários
informando também, as permissões e restrições de
acesso impostas a este novo grupo.
Fluxo típico
O administrador acessa o sistema. Em seguida solicita a
criação de um novo Grupo de Usuários, define o nome
do Grupo, bem como suas permissões de acesso.
O administrador poderá, também, adicionar contas de
usuários no Grupo recém criado.
O administrador confirma a criação do Grupo.
Atores:
Administrador da Rede - É o operador do sistema
A figura seguinte [Figura 10] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A3.
34
Figura 10 - Esquema de interação da atividade A4.
8.2.5 Caso de Uso – A5 (Editar Grupos)
Nome
Editar Grupos
Objetivo
Incluir/Excluir conta(s) de usuários de um determinado
grupo. Alterar nome e/ou atributos do grupo.
Descrição
O Administrador altera a composição de usuários em
determinado grupo. Podendo inserir ou excluir usuários
do grupo.
O Administrador também pode alterar o nome do grupo.
Atores:
Administrador da Rede - É o operador do sistema
8.2.5.1 Fluxo Expandido
Descrição
Incluir/Excluir conta(s) de usuários de um determinado
grupo. Alterar nome do grupo.
Fluxo típico
O Administrador localiza o Grupo de usuários mo
sistema.
O Administrador insere novas Contas de Usuários no
Grupo ou exclui Contas de Usuários do Grupo.
O Administrador faz alterações nos atributos do Grupo
como: nome, permissões,...
Atores:
Administrador da Rede - É o operador do sistema
35
A figura abaixo [Figura 11] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A5.
Figura 11 - Esquema de interação da atividade A5.
8.2.6 Caso de Uso – A6 (Trocar Senha)
Nome
Trocar Senha
Objetivo
Trocar senha de uma conta de Usuário
Descrição
O Administrador da Rede altera a senha de acesso de
um usuário qualquer.
Atores:
Administrador da Rede - É o operador do sistema;
Usuário - Usuário da Rede.
8.2.6.1 Fluxo Expandido
Descrição
O Administrador da Rede altera a senha de acesso de
um usuário qualquer.
Fluxo típico
O Usuário solicita a alteração da senha de sua conta na
rede.
O Administrador da Rede acessa o Sistema, localiza a
Conta do Usuário e solicita a operação de troca de
senha da Conta.
O usuário digita a senha antiga, digita uma senha nova e
digita novamente a mesma senha nova.
O Administrador confirma a alteração da senha e salva
36
os atributos da Conta do Usuário no Sistema.
Atores:
Administrador da Rede - É o operador do sistema;
Usuário - Usuário da Rede.
A figura abaixo [Figura 12] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A6.
Figura 12 - Esquema de interação da atividade A6.
8.2.7 Caso de Uso – A7 (Backup)
Nome
Backup
Objetivo
Fazer e restaurar um backup da base de dados.
Descrição
O Administrador da Rede faz um backup da base de
dados LDAP no formato padrão LDIF. O Administrador
da Rede restaura os dados da base LDAP a partir de um
arquivo padrão LDIF.
Atores:
Administrador da Rede - É o operador do sistema
8.2.7.1 Fluxo Expandido
Descrição
O Administrador da Rede faz um backup da base de
dados LDAP no formato padrão LDIF. O Administrador
da Rede restaura os dados da base LDAP a partir de um
arquivo padrão LDIF.
Fluxo típico 1
O Administrador da Rede acessa o Sistema e solicita a
criação de um Backup da Base LDAP.
(Faz Backup)
37
O Administrador indica o local onde será salvo o arquivo
de Backup e em seguida o sistema gera o Backup no
local definido.
Fluxo típico 2
O Administrador da Rede acesso o Sistema e solicita a
(Restaura Backup) Restauração de um Backup para a Base LDAP.
O Administrador localiza o Arquivo de Backup nos
diretórios da máquina e confirma o processo de
Restauração.
Atores:
Administrador da Rede - É o operador do sistema
A figura abaixo [Figura 13] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A7.
Figura 13 - Esquema de interação da atividade A7.
8.2.8 Caso de Uso – A8 (Editar Schemas disponíveis no diretório)
Nome
Editar Schemas disponíveis no diretório
Objetivo
Permitir a adição de novos esquemas no diretório,
viabilizando assim a adição de novos atributos.
Descrição
O administrador acessa o sistema e faz a madificacao
dos Schemas através das configurações gerais do
Servidor.
Atores
Administrador da Rede - É o operador do sistema
38
8.2.9 Caso de Uso – A9 (Replicação)
Nome
Replicação
Objetivo
Permitir a configuração de um ambiente replicado, ou
seja, utilizando os componentes disponíveis no
OpenLDAP, gerar a configuração necessária para que
outro servidor de diretórios receba todas as modificações
feitas no servidor denominado como principal.
Descrição
O administrador acessa o sistema e solicita a criação de
um arquivo de Backup contendo as informações e
configurações atuais da Base LDAP.
Atores
Administrador da Rede - É o operador do sistema
A figura abaixo [Figura 14] demonstra uma interação entre os atores e o
sistema para a realização da tarefa A9.
Figura 14 - Esquema de interação da atividade A9
39
9. Desenvolvimento
9.1 Atividades de inicialização do sistema
Antes mesmo de realizar as Atividades ditas acima como principais de um
Administrador de Redes, este, precisa conectar-se e ser autorizado em dado
domínio do servidor LDAP, para com isso definir e exibir as atividades a serem
disponibilizadas ao Administrador.
9.1.1 Login no Sistema
A interface de login no Sistema, como já definimos anteriormente, será
executada através de páginas JSP que contenham TAGs referentes à
componentes de interface JSF. A tarefa de login é iniciada através da página
‘index.jsp’, no entanto devido à dependência e composição das páginas JSPs com
as estruturas JSFs trataremos estas páginas JSPs como sendo páginas JSFs.
A seqüência de passos, páginas e classes envolvidas no login para a
montagem do ambiente operacional, estão descritas no diagrama de seqüência
mostrado abaixo [Figura 15].
Figura 15 – Diagrama de seqüência para acesso ao sistema.
9.1.1.1 Descrição dos Passos de Fluxo:
01. forward – a página ‘index.jsp’ inicialmente apresenta a página ‘login.jsf’ no
canto esquerdo do Browser da Internet. A página ‘login.jsf’ [Figura 16]
possui um formulário com campos de entrada de dados para a autenticação
do administrador (domínio, login/nome, senha) e botão para submeter o
formulário à classe seguinte.
40
Figura 16 – página login.jsf
02. loginBean.login() – a página ‘login.jsf’ passa à classe JavaBean,
‘loginBean.java’ os dados de acesso (servidor, identificação e senha) do
administrador do sistema ao qual pretende efetuar a conexão. De acordo
com as possibilidades apresentadas pelo JSF, os dados são passados
automaticamente para a ‘loginBean’ através dos métodos ‘get’ de
‘loginBean’.
03. con.fazLogin(servidor, administrador, senha) – a classe ‘loginBean.java’
cria uma instância da classe de conexão ‘conectaBean.java’ e transmite os
dados colhidos de servidor, identificação e senha do administrador para a
classe ‘conectaBean.java’.
04. lc.connect(servidor, administrador, senha) – a classe ‘conectaBean.java’
tenta fazer o login no servidor LDAP e retorna a informação de sucesso ou
falha na conexão. Caso a conexão seja feita, é retornado um objeto
‘LDAPConnection’ que representa a conexão com o servidor LDAP.
41
05. config.salvaDadosXML(servidor, administrador, senha) – a classe
‘loginBean.java’ cria uma instância da classe ‘configuracoesBean.java’
passando os dados de acesso do administrador.
06. config.salvaDadosXML(servidor, administrador, senha) – a classe
‘configuracoesBean.java’ envia ao arquivo ‘wldapconfig.xml’ os dados de
acesso do administrador para que seja guardado no arquivo.
07. forward – o sistema redireciona a página ‘menu.jsf’ para o canto esquerdo
da página principal.
08. menuBean.treeModel() – a página ‘menu.jsf’ solicita à clasase
‘menuBean.java’ que retorne um menu ‘Tree2’ da biblioteca JSF ‘MyFaces’.
09. menuBean.getTreeModel() – a classe ‘menuBean.java’ consulta o servidor
LDAP para montar o menu com as informações das contas de ‘Grupos’ e
‘Usuários’ cadastrados no sistema.
10. menuBean.treeModel() – a classe ‘menuBean.java’ retorna o menu ‘Tree2’
para a página ‘menu.jsf’.
A seguir, uma visualização da página principal do sistema [Figura 17]. Tendo
em destaque a página ‘menu.jsf’, onde os dados de registros das contas da rede
(Grupos e Usuários) são mostrados de forma hierarquizada a partir de um menu
em forma de árvore.
O menu em árvore está dividido em três partes principais:

Raiz de Domínio de Dados do Servidor LDAP;

Ramo (sub-menu) Grupos de Usuários;

Ramo Usuários de Rede;
Em cada ramo de contas do sistema (Grupos e Usuários) temos o
identificador do ramo com um link de acesso para modificação da conta.
As informações são chamadas através do menu em árvore e, visualizadas no
frame à direita, que exibe as opções correspondentes às principais atividades
exercidas pelo administrador de rede [Figura 17].
42
Figura 17 – exibição da página principal do sistema.
9.1.2 Adicionar Grupo
Através do link ‘Adicionar Grupo’ presente na página ‘menu.jsf’ da página
principal do sistema [Figura 17]. É acessada a página ‘adicionaGrupo.jsf’ com o
formulário de dados necessários para incluir um novo grupo no servidor LDAP do
sistema.
A seguir veremos o diagrama de seqüência dos passos para a Adição de
Grupo no servidor LDAP [Figura 18].
43
Figura 18 – diagrama de seqüência para inserir conta Grupo.
9.1.2.1 Descrição dos Passos de Fluxo
01.
link - a página ‘menu.jsf’ chama a página ‘adicionaGrupo.jsf’ a partir do seu
link ‘Adicionar Grupo’. Na página ‘adicionaGrupo.jsf’ está o formulário de
cadastro com as informações necessárias para a inclusão do grupo [Figura
19].
Figura 19 – página adicionar Grupo.
44
02.
grupoBean.adicionaGrupo() – a página ‘adicionaGrupo.jsf’ informa á
classe ‘grupoBean.java’ os dados necessários para o cadastro da nova
conta grupo (cn e gid) e solicita a inclusão do grupo.
03.
con.conecta() - a classe ‘grupoBean.java’ cria uma instância da classe de
conexão ‘conectaBean.java’ para abrir uma conexão com o servidor LDAP.
04.
config.pegaDadosXML() – a classe ‘conectaBean.java’ cria uma instância
da classe ‘configuracoesBean.java’ solicitando os dados correntes das
configurações de acesso para fazer o login no servidor LDAP.
05.
a classe ‘configuracoesBean.java’ consulta os dados de conexão no arquivo
‘wldapconfig.xml’.
06.
o arquivo ‘wldapconfig.xml’ retorna as informações para a classe
‘configuracoesBean.java’.
07.
a classe ‘configuracoesBean.java’ retorna as informações para a classe
‘conectaBean.java’.
08.
conectaBean.connect() – a classe ‘conectaBean.java’ faz a conexão no
servidor LDAP.
09.
o servidor LDAP retorna uma conexão ‘LDAPConnection’.
10.
a classe ‘conectaBean.java’
‘grupoBean.java’.
11.
a classe ‘grupoBean.java’ insere as informações do novo grupo no servidor
LDAP através da conexão LDAPConnection.
12.
forward – a classe ‘grupoBean.java’ redireciona o Browser para a página
‘resposta.jsf’ contendo as informações de sucesso ou falha da inserção do
grupo.
retorna
a
conexão
para
a
classe
45
9.1.3 Adicionar Usuário
Através do link ‘Adicionar Usuário’ presente na página ‘menu.jsf’ da página
principal do sistema [Figura 17]. É acessada a página ‘adicionaUsuário.jsf’ com o
formulário de dados necessários para incluir uma nova conta usuário no servidor
LDAP do sistema.
A seguir veremos o diagrama de seqüência dos passos para a Adição de
Usuário no servidor LDAP [Figura 19].
Figura 19 – diagrama de seqüência para inserir conta Usuário.
9.1.3.1 Descrição dos Passos de Fluxo
01. link - a página ‘menu.jsf’ chama a página ‘adicionaUsuario.jsf’ a partir do
seu link ‘Adicionar Usuário’. Na página ‘adicionaUsuario.jsf’ está o
formulário de cadastro com as informações necessárias para a inclusão do
usuário [Figura 20].
46
Figura 20 – Adicionar Usuário.
02. usuarioBean.adicionaUsuario() – a página ‘adicionaUsuario.jsf’ informa á
classe ‘usuarioBean.java’ os dados necessários para o cadastro da nova
conta usuário (cn e gid) e solicita a inclusão do usuário.
03. con.conecta() - a classe ‘usuarioBean.java’ cria uma instância da classe
de conexão ‘conectaBean.java’ para abrir uma conexão com o servidor
LDAP.
04. config.pegaDadosXML() – a classe ‘conectaBean.java’ cria uma instância
da classe ‘configuracoesBean.java’ solicitando os dados correntes das
configurações de acesso para fazer o login no servidor LDAP.
05. a classe ‘configuracoesBean.java’ consulta os dados de conexão no
arquivo ‘wldapconfig.xml’.
47
06. o arquivo ‘wldapconfig.xml’ retorna as informações para a classe
‘configuracoesBean.java’.
07. a classe ‘configuracoesBean.java’ retorna as informações para a classe
‘conectaBean.java’.
08. conectaBean.connect() – a classe ‘conectaBean.java’ faz a conexão no
servidor LDAP.
09. o servidor LDAP retorna uma conexão ‘LDAPConnection’.
10. a classe ‘conectaBean.java’
‘usuarioBean.java’.
retorna
a
conexão
para
a
classe
11. a classe ‘usuarioBean.java’ insere as informações do novo grupo no
servidor LDAP através da conexão LDAPConnection.
12. forward – a classe ‘usuarioBean.java’ redireciona o Browser para a página
‘resposta.jsf’ contendo as informações de sucesso ou falha da inserção do
usuário.
9.1.4 Alterar Grupo
Através do link de cada identificador do grupo no menu em árvore, Tree2, na
página ‘menu.jsf’ da página principal do sistema [Figura 17], é acessada a página
‘editaGrupo.jsf’ com o formulário de dados necessários para alterar um grupo do
servidor LDAP do sistema.
A seguir veremos o diagrama de seqüência dos passos para a Edição de
Grupo no servidor LDAP [Figura 21].
48
Figura 21 – diagrama de seqüência para editar conta Grupo.
9.1.4.1 Descrição dos Passos de Fluxo
01. link - a página ‘menu.jsf’ chama a página ‘editaGrupo.jsf’ a partir do seu
link ‘Editar Grupo’. Na página ‘editaGrupo.jsf’ está o formulário de edição
com as informações necessárias para a alteração do grupo [Figura 22].
Figura 22 – Página para editar Grupo.
49
02. grupoBean.editaGrupo() – a página ‘editaGrupo.jsf’ informa á classe
‘grupoBean.java’ os dados necessários para o alteração da nova conta (cn
e gid) e solicita a modificação do grupo.
03. con.conecta() - a classe ‘grupoBean.java’ cria uma instância da classe de
conexão ‘conectaBean.java’ para abrir uma conexão com o servidor LDAP.
04. config.pegaDadosXML() – a classe ‘conectaBean.java’ cria uma instância
da classe ‘configuracoesBean.java’ solicitando os dados correntes das
configurações de acesso para fazer o login no servidor LDAP.
05. a classe ‘configuracoesBean.java’ consulta os dados de conexão no
arquivo ‘wldapconfig.xml’.
06. o arquivo ‘wldapconfig.xml’ retorna as informações para a classe
‘configuracoesBean.java’.
07. a classe ‘configuracoesBean.java’ retorna as informações para a classe
‘conectaBean.java’.
08. conectaBean.connect() – a classe ‘conectaBean.java’ faz a conexão no
servidor LDAP.
09. o servidor LDAP retorna uma conexão ‘LDAPConnection’.
10. a classe ‘conectaBean.java’
‘grupoBean.java’.
retorna
a
conexão
para
a
classe
11. a classe ‘grupoBean.java’ altera as informações do grupo no servidor LDAP
através da conexão LDAPConnection.
12. forward – a classe ‘grupoBean.java’ redireciona o Browser para a página
‘resposta.jsf’ contendo as informações de sucesso ou falha da alteração do
grupo.
50
9.1.5 Alterar Usuário
Através do link ‘Alterar Usuário’ presente na página ‘menu.jsf’ da página
principal do sistema [Figura 17]. É acessada a página ‘editaUsuario.jsf’ com o
formulário de dados necessários para alterar uma conta usuário no servidor LDAP
do sistema.
A seguir veremos o diagrama de seqüência dos passos para a Edição de
Usuário no servidor LDAP [Figura 23].
Figura 23 – diagrama de seqüência para editar conta Usuário.
9.1.5.1 Descrição dos Passos de Fluxo
01. link - a página ‘menu.jsf’ chama a página ‘editaUsuario.jsf’ a partir do seu
link ‘Editar Usuário’. Na página ‘editaUsuario.jsf’ está o formulário de edição
com as informações necessárias para a alteração do usuário [Figura 24].
51
Figura 24 – Página editar Usuário.
02. usuarioBean.editaUsuario() – a página ‘editaUsuario.jsf’ informa á classe
‘usuarioBean.java’ os dados necessários para a edição da conta usuário (cn
e gid) e solicita a alteração do usuário.
03. con.conecta() - a classe ‘usuarioBean.java’ cria uma instância da classe
de conexão ‘conectaBean.java’ para abrir uma conexão com o servidor
LDAP.
04. config.pegaDadosXML() – a classe ‘conectaBean.java’ cria uma instância
da classe ‘configuracoesBean.java’ solicitando os dados correntes das
configurações de acesso para fazer o login no servidor LDAP.
05. a classe ‘configuracoesBean.java’ consulta os dados de conexão no
arquivo ‘wldapconfig.xml’.
52
06. o arquivo ‘wldapconfig.xml’ retorna as informações para a classe
‘configuracoesBean.java’.
07. a classe ‘configuracoesBean.java’ retorna as informações para a classe
‘conectaBean.java’.
08. conectaBean.connect() – a classe ‘conectaBean.java’ faz a conexão no
servidor LDAP.
09. o servidor LDAP retorna uma conexão ‘LDAPConnection’.
10. a classe ‘conectaBean.java’
‘usuarioBean.java’.
retorna
a
conexão
para
a
classe
11. a classe ‘usuarioBean.java’ altera as informações do grupo no servidor
LDAP através da conexão LDAPConnection.
12. forward – a classe ‘usuarioBean.java’ redireciona o Browser para a página
‘resposta.jsf’ contendo as informações de sucesso ou falha da edição do
usuário.
53
10. Considerações Finais
OBSERVAÇÕES:
Aos Membros da Banca,
Como pôde-se perceber, o documento (rascunho) ainda não está completo,
faltando ainda documentar algumas classes e atividade que estão em fase
de conclusão e testes finais.
Portanto ficam aqui, em branco, no momento, as considerações finais e a
conclusão do documento, estando este completo, com mais alguns dias
(antes da apresentação).
54
11. Conclusão
55
12. Referências Bibliográficas
[HSG1998] Howes, Timothy A.; Smith, Mark C.; Good, Gordon S. - Understanding and Deploying
LDAP Directory Services, New Riders Publishing, 1ª Edição – Dezembro 1998.
[CARTER2003] Carter, Gerald - LDAP System Administration, O’reilly, March 2003.
[DEITEL2003] Deitel, H. M. e Deitel, P. J. – Java – Como Programar, 4ª Edição – 2003
[JSPBRA01] J2EEBrasil - O site da comunidade J2EE no Brasil. Telêmaco, Ulisses – O que é JSP.
Disponível em: http://www.jspbrasil.com.br/jsp/tutoriais/tutorial.jsp?idTutorial=001_001.
Acesso em 13 de outubro de 2005.
[JSPBRA11] J2EEBrasil - O site da comunidade J2EE no Brasil. Lima, Gleydson – JavaBeans em
JSP. Disponível em:
http://www.jspbrasil.com.br/jsp/tutoriais/tutorial.jsp?idTutorial=001_011.
Acesso em 14 de outubro de 2005.
[JSPBRA13] J2EEBrasil - O site da comunidade J2EE no Brasil. Sanchez, Otávio Henrique Vieira –
Servlets. Disponível em: http://www.jspbrasil.com.br/jsp/tutoriais/tutorial.jsp?idTutorial=001_013.
Acesso em 13 de outubro de 2005.
[LDAPLICEU01] LDAP – Lightweight Directory Access Protocol – PHPLDAPADMIN. Disponível
em: http://www.ldap.liceu.com.br/imprementacao/ferramentas_adm/phldapadmin.htm. Acesso em
25 de outubro de 2005.
[LDAPLICEU02] LDAP – Lightweight Directory Access Protocol – LDAP Browser/Editor.
Disponível em: http://www.ldap.liceu.com.br/imprementacao/ferramentas_adm/ldap_browser.htm.
Acesso em 25 de outubro de 2005.
[LDAPBE] Lightweight Directory Access Protocol – LDAP Browser/Editor version 2.8.1.
Disponível em: http://www-unix.mcs.anl.gov/~gawor/ldap/. Acesso em 22 de setembro de 2005.
[PHPLDAPADMIN] PhpLDAPadmin: LDAP Browser To Manager Your LDAP Server. Disponível
em: http://phpldapadmin.sourceforge.net/. Acesso em 22 de setembro de 2005.
[SMBLDAP] Sena, Clovis (tradução) – Manual do Usuário do Smbldap-Tools. Disponível em:
http://www.ldap.org.br/modules/ldap/files/files/manual_smbldap-tools.pdf. Acesso em 11 de
novembro de 2005.
56
[LARMAN2000] Larman, Craig – Utilizando UML e Padrões. Uma Introdução à Análise e ao
Projeto Orientados a Objetos. Editora Bookman – Porto Alegre, 2000.
[BERGSTEN] Bergsten, Hans. 2004. Improving JSF by Dumping JSP. Disponível Em:
http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html. Acesso em 25 de maio de 2006.
[HOLMES] Holmes, James. Faces Console JSF configuration editor. Disponível em:
http://www.jamesholmes.com/JavaServerFaces/console. Acesso em 12 de junho de 2006.
[JSFCENTRAL] JSF Central JavaServer Faces community and FAQ – Disponível em:
http://www.jsfcentral.com. Acesso em 12 de junho de 2006.
[MYFACES] MyFaces open source JSF implementation. Disponível em: http://www.myfaces.org.
Acesso em 18 de junho de 2006.
[MANN] Kito D. Mann, Javaserver Faces In Action, Manning - 2004
[JSFSPEC] Sun Microsystems. JavaServer Faces specification.
http://java.sun.com/j2ee/javaserverfaces. Acesso em 01 de julho de 2006.
Disponível
em:
57
Download