Embed Size (px)
Citation preview
UNIVERSIDADE DO ESTADO DE SANTA CATARINA
BACHARELADO EM CIENCIA DA COMPUTACAO
Franscielly Benvenutti Eccel
Uma Proposta de Implementacao do Protocolo LDAP
no Centro de Ciencias Tecnologicas da UDESC
Monografia submetida a Universidade do Estado de Santa Catarina como parte dos requi-
sitos para a obtencao do grau de Bacharelado em Ciencia da Computacao.
Prof. Charles Christian Miers, M.Sc.
Orientador
Prof. Ricardo Ferreira Martins, M.Eng.
CoOrientador
Joinville, Novembro de 2005
Uma Proposta de Implementacao do Protocolo LDAP no
Centro de Ciencias Tecnologicas da UDESC
Franscielly Benvenutti Eccel
Esta Monografia foi julgada adequada para a obtencao do tıtulo de Bacharelado em Ciencia
da Computacao, Area de Concentracao Sistemas de Computacao, e aprovada em sua
forma final pelo Departamento de Ciencia da Computacao.
Prof. Charles Christian Miers, M.Sc.
Orientador
Prof. Ricardo Ferreira Martins, M.Eng.
CoOrientador
Prof. Jose Luiz Mendes, M.Sc.
Coordenador do Curso
Banca Examinadora
Prof. Charles Christian Miers, M.Sc.
Prof. Kariston Pereira, M.Sc.
Prof. Adriano Fiorese, M.Sc.
iii
”Construa voce mesmo sua vida, nao permita que opinioes e erros alheios oconduzam ao fracasso. Transforme-se naquilo que almeje ser.”
Vera Lucia Benvenutti Eccel
iv
Aos meus pais Joao Domingo Eccel e Vera Lucia Benvenutti Eccel.
Agradecimentos
Primeiramente a Deus, pela dadiva da vida e pela forca espiritual para
alcancar todos os sonhos almejados.
Aos meus pais que com muito esforco, dedicacao e carinho possibilita-
ram para que mais esta etapa de minha vida fosse concluıda e tambem por se privarem
de minha companhia durante esses anos, para que assim eu pudesse realizar um de seus
sonhos.
As minhas irmas, Bruna e Camila, pelo carinho e pela compreensao
diante dos momentos em que estive ausente.
Ao Professor Charles Christian Miers, pessoa pela qual tenho muita
admiracao, agradeco-lhe pelo incentivo a realizacao e apoio fornecido durante o desen-
volvimento deste trabalho.
A todos os professores da UDESC, que de alguma forma contribuıram
para o meu crescimento intelectual e cientıfico.
Sumario
Lista de Figuras ix
Lista de Tabelas xii
Resumo xv
Abstract xvi
1 Introducao 1
1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Trabalhos Correlacionados . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Metodologia Empregada . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Organizacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Conceitos Basicos 8
2.1 Historico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Servicos de Diretorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 X.500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 DAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 LDAP 28
3.1 Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
vii
3.2 Arquitetura/Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Versoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Modelo de Informacao . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2 Modelo de Nome . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.3 Modelo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.4 Modelo de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4 Modelagem de Identidades . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4 OpenLDAP 71
4.1 Slapd e Slurpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.1 Replicacao com slurpd . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.2 Autenticacao e Autorizacao . . . . . . . . . . . . . . . . . . . . 77
4.2 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5 Analise e Modelagem das Identidades dos Sistemas da UDESC 79
5.1 Sistemas e Servicos Existentes . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.1 SigmaWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1.2 Pergamum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.3 Sistema de Empenho . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1.4 Sistema de Viagens . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1.5 Intranet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.6 Sistema de Bolsas de Apoio Discente . . . . . . . . . . . . . . . 85
5.1.7 Conta de Acesso ao Domınio . . . . . . . . . . . . . . . . . . . . 87
5.1.8 Correio Eletronico . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.9 Servico de ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.10 Servico de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2 Estrutura do Diretorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
viii
5.3 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6 Consideracoes Finais 97
Referencias Bibliograficas 100
A Plano de Trabalho 106
B Cronograma do Trabalho 107
C Configuracao do OpenLDAP no Linux 108
D Tela de Dados do SigmaWeb 110
E Telas de cadastro do Pergamum 111
F Ficha de Pre-Empenho 115
G Telas de Cadastro de Empenho 116
H Telas do Sistema de Viagens 118
I Tela da Intranet 120
J Telas do Cadastro do Sistema de Bolsa 121
K Ficha de Dados 123
L Telas de Cadastro de Solicitacao de ADSL 124
M Implementacao do modelo proposto 126
Lista de Figuras
2.1 Surgimento do LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Linha do Tempo dos Servicos de Diretorio . . . . . . . . . . . . . . . . . 10
2.3 Comunicacao do DAP com o Servidor X.500 . . . . . . . . . . . . . . . 11
2.4 Comunicacao do LDAP com o Servidor X.500 . . . . . . . . . . . . . . 11
2.5 Arvore de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Requisicao e resposta de dados . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Comunicacao entre usuarios/recursos . . . . . . . . . . . . . . . . . . . . 16
2.8 Arvore de Informacoes de Diretorio . . . . . . . . . . . . . . . . . . . . 17
2.9 Comunicacao cliente/servidor baseada no LDAP como intermediario para
requisicoes DAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.10 Comunicacao cliente/servidor LDAP atraves de operacoes . . . . . . . . 21
3.1 Representacao dos modelos OSI e DARPA . . . . . . . . . . . . . . . . . 30
3.2 Representacao do PDU e de seu formato . . . . . . . . . . . . . . . . . . 30
3.3 Topologia de rede transparente para usuarios . . . . . . . . . . . . . . . . 36
3.4 Entradas e Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Exemplo de uma Arvore de Informacoes de Diretorio . . . . . . . . . . . 43
3.6 Divisao de ramos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.7 Servidor LDAP retornando referencia ao pedido . . . . . . . . . . . . . . 45
3.8 Servidor LDAP retornando resposta ao pedido . . . . . . . . . . . . . . . 46
3.9 Busca com escopo igual a base . . . . . . . . . . . . . . . . . . . . . . . 49
3.10 Busca com escopo igual a um nıvel da DIT . . . . . . . . . . . . . . . . 49
x
3.11 Busca onde o escopo envolve uma parte da arvore . . . . . . . . . . . . . 50
3.12 Modificacao de DN onde a hierarquia permanece a mesma . . . . . . . . 52
3.13 Modificacao de DN com mudanca na hierarquia . . . . . . . . . . . . . . 53
3.14 Modificacao de DN mantendo o antigo . . . . . . . . . . . . . . . . . . . 54
3.15 Protecao ao meio de transmissao das informacoes . . . . . . . . . . . . . 59
3.16 Analise da Identidade Digital. Adaptado de [Chong, 2004] . . . . . . . . 61
3.17 Exemplo de alguns componentes logicos. Adaptado de [Chong, 2004] . . 63
3.18 Nıveis do ciclo de vida de uma identidade . . . . . . . . . . . . . . . . . 64
3.19 Exemplo da utilizacao de varias identidades para diferentes sistemas. Adap-
tado de [Chong, 2004] . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.20 Exemplo da integracao de identidades de varios sistemas em uma unica
identidade digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.21 Exemplo da integracao de dados de varios sistemas em uma unica identi-
dade digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1 Elementos usados para configuracao do slapd . . . . . . . . . . . . . . . 72
4.2 Elementos que constituem a DIT para OpenLDAP . . . . . . . . . . . . . 74
4.3 Replicacao de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.4 Comunicacao entre o Slapd Mestre e o Escravo . . . . . . . . . . . . . . 76
4.5 Processo Slurpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1 Tela de autenticacao do SigmaWeb . . . . . . . . . . . . . . . . . . . . . 80
5.2 Tela de Cadastro de Usuario do Pergamum . . . . . . . . . . . . . . . . . 82
5.3 Tela de Autenticacao do Sistema de Viagens . . . . . . . . . . . . . . . . 84
5.4 Tela de Autenticacao da Intranet . . . . . . . . . . . . . . . . . . . . . . 85
5.5 Tela de Autenticacao do Sistema de Bolsas de Apoio Discente . . . . . . 86
5.6 Representacao da Arvore de Diretorios . . . . . . . . . . . . . . . . . . . 90
5.7 Modelo que representa os nıveis de acesso . . . . . . . . . . . . . . . . . 91
5.8 Modelo de diretorios e seus respectivos dados . . . . . . . . . . . . . . . 92
B.1 Cronograma Geral: Previsto X Realizado . . . . . . . . . . . . . . . . . 107
xi
D.1 Tela de Dados do SigmaWeb . . . . . . . . . . . . . . . . . . . . . . . . 110
E.1 Tela Validade do Cadastro de Usuario do Pergamum . . . . . . . . . . . . 111
E.2 Tela Area de Conhecimento do Cadastro de Usuario do Pergamum . . . . 112
E.3 Tela Base de Dados do Cadastro de Usuario do Pergamum . . . . . . . . 112
E.4 Tela Dados Responsavel do Cadastro de Usuario do Pergamum . . . . . . 113
E.5 Tela Unidade Organizacional do Cadastro de Usuario do Pergamum . . . 113
E.6 Tela Emprestimo - Senha do Cadastro de Usuario do Pergamum . . . . . 114
F.1 Ficha com as informacoes necessarias para realizar uma solicitacao de
empenho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
G.1 Tela de Dados do Sistema de Empenho . . . . . . . . . . . . . . . . . . . 116
G.2 Tela de Dados do Sistema de Empenho . . . . . . . . . . . . . . . . . . . 117
H.1 Tela de Identificacao do Sistema de Viagens . . . . . . . . . . . . . . . . 118
H.2 Tela de Solicitacao do Sistema de Viagens . . . . . . . . . . . . . . . . . 119
I.1 Tela de servicos disponibilizados pela Intranet . . . . . . . . . . . . . . . 120
J.1 Tela de Cadastro do Sistema de Bolsa . . . . . . . . . . . . . . . . . . . 121
J.2 Tela de Identificacao do Sistema de Bolsa . . . . . . . . . . . . . . . . . 122
J.3 Tela de Dados do Sistema de Bolsa . . . . . . . . . . . . . . . . . . . . . 122
K.1 Ficha de Dados para Solicitacao de Servicos . . . . . . . . . . . . . . . . 123
L.1 Termo de Acordo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
L.2 Tela de Cadastro de Solicitacao de ADSL . . . . . . . . . . . . . . . . . 125
M.1 Tela de demonstracao da implementacao do que foi proposto . . . . . . . 126
Lista de Tabelas
3.1 Operacoes LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Exemplos de Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Exemplos de atributos relacionados as suas sintaxes . . . . . . . . . . . . 41
3.4 Relacao dos principais atributos com suas respectivas representacoes . . . 44
4.1 Componentes do OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1 Siglas que diferenciam a atuacao . . . . . . . . . . . . . . . . . . . . . . 87
5.2 Tipos de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3 Exemplos de contas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4 Exemplos de e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Lista de Siglas
ACI Access Control Information
AD Active Directory
CAV Centro de Ciencias Agroveterinarias
CCE-FAED Centro de Ciencias da Educacao
CCT Centro de Ciencias Tecnologicas
CEAD Centro de Educacao a Distancia
CEART Centro de Artes
CEO Centro Educacional do Oeste
CEFID Centro de Educacao Fısica, Fisioterapia e Desportos
DAP Directory Access Protocol
DIB Directory Information Base
DIT Directory Information Tree
DN Distinguished Name
DNS Domain Name System
DS Distinguished Name
DSA Directory System Agent
ESAG Escola Superior de Administracao e Gerencia
ISO Organization for Standardization
ITU-T International Telecomunication Union - Telecomunication
LDAP Lightweight Directory Access Protocol
LDBM Lightweight Database Management
xiv
NDS Novell Directory Services
NIS Network Information Service
OID Unique Object Identifier
OSI Open System Interconnection
PDU Protocol Data Unit
RDBMS Relational Database Management System
RDN Relative Distinguished Name
RFC Request For Comments
SASL Simple Authentication and Security Layer
SO Sistema Operacional
SQL Structured Query Language
SSL Secure Socket Layer
SSO Single Sign-On
TLS Transport Layer Security
UDESC Universidade do Estado de Santa Catarina
Resumo
Nesta monografia sao abordados os conceitos que envolvem o LDAP
(Lightweight Directory Access Protocol) desde a sua origem ate suas aplicacoes, in-
cluindo as suas estruturas, modelos, versoes e funcionalidades. Objetiva-se o entendi-
mento dos elementos envolvidos no funcionamento e uso do LDAP como fundamento
para elaboracao de um modelo a ser empregado no Campus Joinville do Centro de Ciencias
Tecnologicas da Universidade do Estado de Santa Catarina (CCT/UDESC). A metodo-
logia adotada foi o estudo das especificacoes e das necessidades dos servicos de di-
retorios, a fim de compreender como sao tratadas as informacoes e como e realizado
o acesso/gerencia destas dentro do diretorio. Uma vez compreendido o funcionamento
tem-se as diversas arquiteturas e questoes pertinentes a forma de como implementar os
servicos de diretorios, visto que, o fato de uma infra-estrutura adequada nao implica em
uma implementacao que atenda as necessidades. Sob esses aspectos e relevante avaliar
o que as principais ferramentas disponibilizam de recursos e como estruturar (modelar)
uma infra-estrutura de LDAP adequadamente. Apos a fundamentacao teorica, e perante
as analises das funcionalidades e ferramentas, uma proposta de implementacao foi es-
pecificada com base nos principais sistemas e servicos existentes no CCT/UDESC. Esta
proposta visa, de uma forma generica, servir como plataforma comum para abranger e
integrar todas as formas de autenticacao, assim como as informacoes de proposito geral
sobre os usuarios.
Palavras Chaves: LDAP, Diretorios, Modelagem de Diretorios, Identidade
Abstract
A Proposal of Implementation of LDAP in CCT/UDESC.
Within this thesis are approached the concepts regarding Lightweight
Directory Access Protocol - LDAP: From its origins to its applications, including its
structures, models versions and functionalities. An objective is understanding the main
elements pertaining to the functioning and use of LDAP as a base for elaborating a model
to be applied at the Joinville Campus of the Technological Sciences Center of the Santa
Catarina State University - CCT/UDESC. The adopted methodology was the study of
specifications and the directories service’s necessities, in order to understand how infor-
mation is handled and how its access and management is performed inside the directory.
Once the concept of how the system works is grasped, several architecture models can be
considered, as well as pertaining questions related to the implementation options for the
directory service, as for the fact that a suitable architecture does not imply an implemen-
tation that fulfills all requirements. It is relevant to evaluate, under those aspects, what
devices the main tools available provide and how to structure (model) an adequate LDAP
infra-structure. After the theoretical groundwork and with the result of the analysis of
tools and functionalities presented, an implementation proposal was specified, based on
the major CCT/UDESC existing systems and services. This proposal aims, in a general
way, to comprehend and integrate all forms of authentication as well as general purpose
information about the users.
Key words: LDAP, Directories, Modelling of Directories, Identities
Capıtulo 1
Introducao
Devido a crescente velocidade/quantidade na qual os meios de compu-
tacionais, baseados em redes de computadores, estao sendo adotados surgiram varias for-
mas de aprimorar a troca de informacoes entre pessoas e esses elementos computacionais.
Este progresso deu-se em conjunto com o avanco tecnologico e com outros fatores que
evidenciam as formas de interacao, buscando maior sinergia com nıveis de complexidade
menor no uso (mas, varias vezes, com aumento da complexidade de implementacao). A
comunicacao entre as pessoas pode ser realizada de distintas maneiras e proporcionar a
troca de uma consideravel variedade de dados, porem nem sempre este processo e feito
com a seguranca adequada (o que pode ser ocasionado quer por falhas tecnicas de soft-
ware ou erro humano). [Carneiro, 2005] [Tanenbaum, 1997]
Garantir que as informacoes sejam acessadas com seguranca, mantendo
sua integridade e proporcionando maior disponibilidade, e algo que cada vez mais torna-
se fundamental para o correto funcionamento dos sistemas computacionais, sendo as-
sim a sua implementacao uma necessidade basica. [NBR, 2001] Diante da busca por:
informacoes, padroes, protocolos e outros ıtens que atendam a esses requisitos trazem
como benefıcio aos sistemas informatizados um maior nıvel de estabilidade e confianca.
Tais caracterısticas sao em decorrencia do uso e pesquisa intensiva que produzem a cada
nova versao mais recursos atrelados aos requisitos de seguranca necessarios.
A necessidade de integrar sistemas de autenticacao cresceu para possi-
2
bilitar a organizacao das informacoes, a fim de facilitar o gerenciamento e a comunicacao.
Com isso, varios servicos foram desenvolvidos solucionando problemas existentes com
o compartilhamento da identificacao atraves de grupos de usuarios e com formas de
autenticacao baseados em mecanismos de verificacao da identidade digital1, como me-
canismos de login e senha, entre outros. [Wanderley, 2005]
Estas formas de autenticacao devem ser estabelecidas previamente, de
maneira que um acesso seja disponibilizado ao usuario pelo servidor. Assim sendo, um
cadastro e gerado, contendo os respectivos dados, e estes sao armazenados dentro de uma
estrutura apropriada denominada de diretorio.
O armazenamento das informacoes referentes a identidade digital, e
acessos relacionados a essa, e feito em diretorios que sao constituıdos das entradas de
informacoes, chamadas de DN (Distinguished Name), como por exemplo, os dados de
pessoas, empresas, recursos de rede, nomes de computadores, enderecos IP ou enderecos
de e-mail. Alem disso, um diretorio pode ser usado em uma larga faixa de aplicacoes,
como pelos sistemas de Recursos Humanos e de Contabilidade e Financas, sempre bus-
cando realizar uma identificacao unica ou um unico cadastro. [Lozano, 2005]
Um padrao que disponibiliza formas para realizar a conexao e a gerencia
de diretorios locais e o X.500. Seu objetivo e gerar um so diretorio distribuıdo. Com base
na criacao e desenvolvimento deste, o Protocolo de Acesso a Diretorio (DAP - Direc-
tory Access Protocol) foi especificado, porem para atender suas definicoes este protocolo
precisava de consideraveis recursos computacionais para ser executado. [Garcia, 2005]
[Isquierdo, 2001]
Buscando simplificar o processo de manipulacao e gerencia dos dados
foi desenvolvido o LDAP (Lightweight Directory Access Protocol) que e processado di-
retamente sobre a camada de aplicacao da pilha de protocolo TCP/IP e dispoe da maior
parte das funcionalidades do DAP, a um custo muito menor e consumindo menos re-
cursos2. Alem disso, o LDAP foi desenvolvido como um padrao aberto, de modo a fa-
1Identidade digital e uma forma de identificacao, a qual contem informacoes do usuario. [Chong, 2004]2O DAP foi considerado por demais complexo para ser empregado amplamente, pois envolvia muitas
especificacoes para torna-lo operacional.
3
cilitar a sua implementacao nos mais diferentes sistemas e aplicativos, para evitar que
questoes pertinentes a licenciamento pudessem afetar a adesao ao mesmo. [Allen, 2003]
[Naguel, 2005] [Isquierdo, 2001] [Kellermann, 2005]
O LDAP tambem dispoe da utilidade de padronizar o acesso de servicos
e recursos, integrando as senhas e os cadastros de usuarios ou clientes, evitando as-
sim redundancias de dados dentro de um diretorio. Devido ao grande volume de sis-
temas, essa caracterıstica faz com que o uso deste protocolo seja amplamente empre-
gado, divulgando assim sua eficiencia atraves de diversos servicos e aplicacoes, como:
o Netscape, o OpenLDAP e o AD (Active Directory). [Souza, 2005] [Microsoft, 2005]
[Voglmaier, 2004] [Pininga, 2005]
O LDAP e um protocolo que pretende resolver o problema da descen-
tralizacao de informacoes em inumeros sistemas de qualquer empresa de medio e grande
porte, proporcionando agilidade e reducao de custo entre os profissionais. Com o estudo
de sua origem, estrutura, modelos, ferramentas e funcionamento, pode-se constatar que
o LDAP em conjunto com os recursos e as ferramentas atuais, e capaz de proporcionar
a seguranca e a manipulacao das informacoes a uma rede de computadores e aos seus
diretorios, de uma forma adequada.
Deste modo, e importante a criacao de polıticas de controle de acesso
adequada a cada tipo de usuario, aumentando a seguranca e reduzindo os custos atraves
da administracao e controle de forma centralizada, assegurando que somente as pessoas
que tiverem o perfil adequado terao acesso as informacoes e servicos oferecidos. A fim
de integrar sistemas e garantir esse tipo de controle e fundamental que seja feita uma
modelagem dos dados existentes nos sistemas, para criar uma identidade digital, onde
cada usuario tem acesso a varios servicos atraves de uma unica senha que esteja associada
a uma identidade unica. [Kellermann, 2005] [Filho, 2005]
Para criar essa identidade e necessaria a sincronizacao de dados que
residem em diretorios, bancos de dados, sistemas colaborativos e aplicativos. Essa in-
tegracao deve ser feita de forma minuciosa, para que nao haja perda de dados entre os
servicos ou para que somente as informacoes nao replicadas sejam agregadas ao conjunto
de dados finais. Percebe-se entao a complexidade em integrar as varias necessidades dos
4
diversos sistemas/aplicativos em uma estrutura unica (a identidade) de modo a fornecer
um ponto central de controle e gerenciamento, alem desse fato nao pode-se esquecer a
compatibilidade e flexibilidade que essa estrutura deve possuir.
Baseando-se nestas definicoes e conceitos de LDAP, nos motivos que le-
varam ao seu surgimento e sua aplicacao, constata-se que a analise dos sistemas e servicos
existentes no CCT/UDESC3 (do modo como estao estruturados quanto a identificacao
dos usuarios/recursos) mostra-se relevante e plenamente justificavel ao emprego dessa
tecnologia. Tal afirmacao pode ser comprovada fazendo-se uma analogia aos proprios
servicos de diretorios, que surgiram devido a diversidade de sistemas, implicando como
consequencia em varias identificacoes para um mesmo indivıduo/recurso.
Desta forma, o estudo do protocolo LDAP e seus requisitos de espe-
cificacao tornaram-se uteis para possibilitar a elaboracao da proposta de uma identi-
dade/modelo com base nas informacoes dos sistemas e servicos existentes. Esta proposta
de implementacao busca propiciar uma integracao dos dados e um gerenciamento mais
adequado destes, o que leva a ter um ambiente mais seguro e funcional.
1.1 Objetivo Geral
Realizar um estudo sobre a arquitetura e o funcionamento do protocolo
LDAP, com o intuito de verificar os requisitos e necessidade de especificacoes, objeti-
vando sugerir uma proposta de emprego do LDAP no CCT/UDESC (Campus Joinville).
De modo a atingir o objetivo geral estabelecido, determinados ıtens de-
vem ser estudados de modo mais detalhado e que sao assim considerados objetivos es-
pecıficos. Sendo assim, os objetivos especıficos a serem atingidos sao:
• Objetivo especıfico 1 - Relatar conceitos de seguranca da informacao em redes de
computadores.
• Objetivo especıfico 2 - Definir e relatar conceitos de diretorios.
3Centro de Ciencias Tecnologicas / Universidade do Estado de Santa Catarina
5
• Objetivo especıfico 3 - Definir LDAP, pesquisar e relatar sua origem, estrutura,
modelos, requisitos, servicos e funcionamento.
• Objetivo especıfico 4 - Analisar as ferramentas existentes.
• Objetivo especıfico 5 - Analisar e considerar um contexto do CCT/UDESC (Cam-
pus Joinville) buscando identificar pontos em que o conceito de LDAP possa ser
aplicavel.
• Objetivo especıfico 6 - Selecionar entre as ferramentas analisadas uma que satisfaca,
ou seja, a mais apta a satisfazer, os servicos dentro do contexto verificado no Obje-
tivo Especıfico 5.
• Objetivo especıfico 6 - Elaborar uma proposta para um modelo de emprego do pro-
tocolo LDAP no CCT/UDESC (Campus Joinville), preferencialmente realizando a
implementacao deste. Tal proposta compreendera uma modelagem para definicao
de uma identidade adequada a realidade do CCT/UDESC.
Como pode ser observado, nos objetivos especıficos, eles constituem
de varios topicos e fases do trabalho que cumpridos culminam no atendimento do obje-
tivo geral. Deste modo, atingindo os objetivos especıficos de modo adequado tem-se a
indicacao de que o objetivo geral e uma consequencia destes.
Para incrementar ainda mais os resultados obtidos com este trabalho,
uma atividade adicional fora sugerida. Esta contempla a implementacao de uma amostra
do modelo, a fim de visualizar o que foi sugerido. Para tal, deve-se realizar a instalacao e
configuracao conforme mostra o Apendice C.
1.2 Trabalhos Correlacionados
A Universidade Federal do Rio Grande do Sul (UFRGS) desenvolveu
o ”Direto”que consiste em um sistema de agenda, catalogo e correio corporativos desen-
volvido pela Companhia de Processamento de Dados do Estado do Rio Grande do Sul
(PROCERGS). Este surgiu como uma alternativa para a padronizacao da ferramenta de
6
correio dos servidores, buscando melhorar a comunicacao interna e externa e fornecer
recursos de catalogo e agenda corporativos. Alem disso, a implementacao deste utiliza
diversos servicos e tecnologias, entre elas o OpenLDAP, que se baseia na utilizacao de
servidor LDAP. [UFRGS, 2005]
Outro trabalho que envolve a utilizacao das funcionalidades do LDAP
e o ”GT-Diretorios - Uma Arquitetura de Autenticacao e Autorizacao para a Universi-
dade Brasileira”, que foi projetado para ser desenvolvido e estudado pela Universidade
Federal do Parana (UFPR), pela PUC do Rio de Janeiro e pela Universidade Federal de
Minas Gerais (UFMG). Este consiste em realizar uma proposta para investigar e propor
uma solucao para a utilizacao de diretorios pela Rede Nacional de Ensino e Pesquisa.
[Carvalho, 2005c]
Estes trabalhos tem como objetivo realizar/apresentar um estudo das
formas de utilizar e implantar diretorios. Ambos buscam centralizar as informacoes e
garantir a autenticacao e a autorizacao, ou seja, a seguranca dos dados.
1.3 Metodologia Empregada
A metodologia adotada neste trabalho consiste em pesquisas referen-
ciadas (bibliograficas) e pesquisas de campo, buscando os fundamentos necessario apara
atingir os objetivos. Alem dos materiais pesquisados buscou-se orientacoes de outros
professores4, na definicao mais claras das etapas e o teor de seu conteudo, e o auxılio de
funcionarios da Universidade para a coleta de informacoes necessarias. Demais detalhes
especıficos sobre a metodologia podem ser consultados no Apendice A.
4Cita-se como cronologicamente como exemplo as consultas feitas a Profa. Cinara T. Menegazzo, com
embasamento nas aplicacoes existentes, evitando replicar um material feito por seu orientando. Alem disto,
a Profa. Cinara T. Menegazzo auxiliou na coleta de informacoes, sobre os sistemas e servicos da UDESC,
para o desenvolvimento do modelo proposto. O Prof. Ricardo F. Martins ajudando com o desenvolvimento
da modelagem e validando os aspectos mais relevantes para tal. Por final a validacao feita pela Profa.
Avanilde Kemczinski viabilizando as possibilidades de normalizar o modelo proposto.
7
1.4 Organizacao do Trabalho
No capıtulo 2 esta relatado o historico e os conceitos que envolvem o
LDAP. Devido a necessidade de gerenciamento, acesso e integracao de informacoes em
um diretorio. Alem disso, sao esclarecidas definicoes envolventes e as que surgiram a
partir destes conceitos, como o padrao X.500, o DAP, o proprio LDAP. Os modelos, a
estrutura, o funcionamento e a seguranca do LDAP sao explicados e analisados, sendo
aproveitados adiante para realizar um aprofundamento do estudo.
O capıtulo 3 possui a definicao do LDAP, bem como o seu funciona-
mento, versoes, aplicacoes existentes e um maior detalhamento dos modelos, relatando as
operacoes que possibilitam estruturar e gerenciar os dados dentro de um diretorio. Alem
disso, ainda sao especificados a modelagem de identidades, sua importancia e as formas
com que estas podem ser asseguradas e implantadas em aplicacoes para garantir que cada
usuario tenha uma unica identificacao.
O capıtulo 4 apresenta conceitos e definicoes do OpenLDAP, ferramenta
escolhida para a realizacao da proposta de implementacao do LDAP no CCT/UDESC,
bem como informacoes e caracterısticas relevantes a escolha desta. Alem disso, relata
como pode ser feita a comunicacao entre cliente/servidor e como os daemons (slapd e
slurpd) podem auxiliar e viabilizar a utilizacao destes.
O capıtulo 5 relata o levantamento de dados (caracterısticas de cada
sistema/servico, formas de identificacao e de autenticacao e as entradas de informacoes
ou cadastros realizados) e a analise realizada nos sistemas e servicos existentes no CCT/
UDESC. Neste ainda encontra-se a modelagem final sugerida, que foi desenvolvida com
base nos quesitos e informacoes coletadas, analogas ao estudo teorico realizado.
O estudo feito vem realizar o que foi previsto no Plano para este tra-
balho, que segue no Apendice A. Este tem como objetivo especificar o que deveria ser
realizado, as etapas previstas e o cronograma a ser entregue. Com base neste e no cum-
primento das atividades, o objetivo geral pode ser conquistado, o qual destinava uma
proposta de implementacao do LDAP para o CCT/UDESC.
Capıtulo 2
Conceitos Basicos
A integracao de redes de computadores vem sendo explorada e desen-
volvida com o crescimento tecnologico, buscando atingir os objetivos perante a infor-
matizacao, os diferentes fabricantes uniram-se a fim de padronizar e atingir um elevado
nıvel de funcionalidades. [Filho, 2005] A medida em que as necessidades da sociedade
ampliam-se, evoluem tambem a inovacao e o desenvolvimento dos recursos/sistemas exis-
tentes. Diante dessa diversidade de sistemas computacionais tornam-se consideravel-
mente variados os recursos disponibilizados em uma rede de computadores. Para inte-
grar e utilizar de maneira adequada esses dispositivos tornou-se necessaria a existencia
de um sistema de informacoes que localiza e fornece os dados sobre o funcionamento da
rede, com isso, a ISO1 desenvolveu um padrao internacional de sistemas de diretorios2
espelhando-se no modelo de referencia OSI3. [Filho, 2005] [Rhee, 2003]
Este padrao definiu uma serie de protocolos, os quais tem como objetivo
tornar transparente as aplicacoes da rede e a localizacao dos objetos dentro da mesma.
Alem disso, foram disponibilizadas um conjunto de normas para definir como deveriam
ser tratados determinados servicos, como o de diretorios estabelecido pela ISO-9594/N e
pelas recomendacoes da serie X.500 da ITU-T4. [Rhee, 2003]
1Internatinal Standardization Organization.2Um diretorio e uma base de dados especializada com o objetivo de disponibilizar o acesso rapido aos
dados de uma maneira padronizada. [House, 2000]3Open System Interconction.4International Telecomunication Union - Telecomunication.
9
Os servicos de diretorios permitem estruturar os dados, de uma orga-
nizacao, de modo a tornar o acesso facilitado e padronizado. Com a utilizacao dos
diretorios, varias formas de organizar as informacoes dentro deste foram criadas, im-
plicando em uma serie de dificuldades perante a organizacao dos dados, gerando re-
dundancias dentro de diretorios diferentes ou ate mesmo dentro de um diretorio, repetindo
nomes. [Voglmaier, 2004]
Buscando garantir a autenticacao e a integracao destes dados, foram
desenvolvidos servicos baseados na especificacao do padrao X.5005, como o DAP6 (Di-
rectory Access Protocol) e o LDAP7 (Lightweight Directory Access Protocol). Conforme
a Figura 1.1, o LDAP surgiu de uma simplificacao do DAP e estabeleceu uma serie de
especificacoes, criando um protocolo e consequentemente servicos.
Figura 2.1: Surgimento do LDAP
A criacao de servicos de diretorio trouxe consigo uma grande quan-
tidade de conceitos (organizacao em arvores, modelagem, estruturacao de dados, etc.)
e o surgimento de novos servicos de acesso (integracao, autenticacao e seguranca das
informacoes dentro de uma rede). Para integrar-se a este contexto varias ferramentas
vem sendo desenvolvidas, objetivando o uso dos dados disponibilizados no servico de di-
5O X.500 e um protocolo que define um modelo para a conexao e gerencia de servicos de diretorios.
[Garcia, 2005]6O DAP e um protocolo de acesso a diretorios que foi desenvolvido para trabalhar com as especificacoes
do X.500. [GSI, 2005]7O LDAP e um protocolo de acesso e gerenciamento de informacoes de um diretorio, o qual veio para
simplificar as formas de realizar as funcionalidades do DAP. [Kanies, 2001]
10
retorio existente e agregando novos dados, gerando desta forma um aumento significativo
do conteudo disponibilizado no servico de diretorio. Entender a historia e evolucao dos
servicos de diretorio, assim como das aplicacoes que integram-se a ele, permite compre-
ender o estagio em que esta a tecnologia e as motivacoes que conduziram a essa realidade.
2.1 Historico
Em 1988 surgiu o padrao X.500, desenvolvido por Marshall Rose e
Martin Schoffstall, que define o modelo para realizar a conexao e a gerencia de servicos
de diretorios locais afim de gerar um diretorio global e distribuıdo. O servico de diretorio
X.500 foi criado para disponibilizar, alterar, adicionar e excluir informacoes em diretorios,
como dados de pessoas, organizacoes, enderecos de correio eletronico, enderecos de rede,
aplicacoes, autorizacoes de acesso, recursos computacionais, produtos, servicos, entre ou-
tros. Nesta epoca ja constatava-se problemas, como a duplicidade e paridade por exemplo,
referentes nao somente aos dados armazenados nas redes, mas do proprio modo que estes
eram organizados e estruturados. [Pohlman, 2003] A partir de sua criacao varios proto-
colos, padroes e servicos foram designados a este fim, a Figura 2.2 mostra os principais
desenvolvimentos neste segmento sob uma linha do tempo.
Figura 2.2: Linha do Tempo dos Servicos de Diretorio
Paralelo ao surgimento do X.500 e para a realizacao de um trabalho
mutuo foi desenvolvido um protocolo de acesso a diretorios (DAP), conforme mostra a
11
Figura 2.3. O DAP originou-se para realizar seu trabalho baseando-se no modelo OSI8
completo e envolvia muitas especificacoes para torna-lo operacional. Alem disso, para
obter seu funcionamento de forma esperada, este protocolo precisa de consideraveis re-
cursos computacionais, pois o banco de dados que utiliza os servicos de diretorio foi
desenvolvido para ser armazenado na memoria, fazendo com que seu uso seja inviavel.
[Vitorio, 2005] [Pohlman, 2003]
Figura 2.3: Comunicacao do DAP com o Servidor X.500
Buscando simplificar o processo de manipulacao e gerencia dos dados
e disponibilizar o acesso deste servico a rede com menos recursos foi desenvolvido, em
1993, o LDAP. Este protocolo e processado diretamente sobre a camada de aplicacao
da pilha de protocolo TCP/IP e possui a maior parte das funcionalidades do DAP, a um
custo muito menor e consumindo menos recursos, como pode ser observado na Figura
2.4. [Carter, 2003]
Figura 2.4: Comunicacao do LDAP com o Servidor X.500
Varios tipos de servicos surgiram buscando implementar a utilizacao
do protocolo LDAP, como o AD (Active Directory) em 2000 e o OpenLDAP em 1998.
8O modelo OSI foi criado em 1977 pela ISO com o objetivo de criar padroes de conectividade para
interligar sistemas de computadores locais e remotos. Este divide os protocolos de rede em sete camadas:
Fısica, Enlace, Rede, Transporte, Sessao, Apresentacao e Aplicacao.
12
O OpenLDAP foi implementado sob modelo de software livre9 para os usuarios Unix e
GNU/Linux fornecendo suporte para replicacao de servidores e integracao com demais
servidores LDAP de outras plataformas. O AD e um servico que serve para realizar o
armazenamento para recuperacao de informacoes e dar suporte ao LDAP. Sendo projetado
pela Microsoft e uma solucao proprietaria e foi idealizado para ser totalmente integrado
a arquiteturas MS-Windows 2000 e posteriores, visando uma possibilidade de integracao
com outras plataformas (apesar de possuir recursos que somente sao funcionais para a
plataforma Microsoft). [Craft, 2001] [Hoffman, 2004] [Kellermann, 2005]
A aplicacao e o desenvolvimento dos padroes, protocolos e servicos fez
com que varias empresas, instituicoes e usuarios comuns passassem a implantar e utili-
zar estes meios de realizar acesso e gerenciamento em diretorios. Com isso, os clientes
buscam concentrar seus dados em apenas um diretorio, fazendo com que diminuam as
informacoes redundantes, facilitar a gerencia e os acessos nao autorizados na rede.
2.2 Servicos de Diretorios
Um diretorio e um banco de dados especializado em armazenar infor-
macoes descritivas, baseadas em atributo. Este permite compartilhar dados entre apli-
cacoes, controlar o acesso de dados, distribuir a gerencia das informacoes e extende-las
com facilidade. Alem disso, um diretorio e organizado em forma de arvore (hierarqui-
camente) e nao de tabela como os bancos de dados tradicionais. A Figura 2.5 apresenta
um exemplo onde estao dispostos tres servidores e seus respectivos dados. [Carter, 2003]
[House, 2000]
Geralmente um diretorio serve para que as informacoes sejam lidas.
Em consequencia disto, pode-se dizer que os diretorios normalmente nao sao usados para
implementar transacoes complexas, ou esquemas de consultas regulares em bancos de da-
dos, eles sao preparados para responder a um grande volume de consultas ou operacoes
de busca. Alem disso, os diretorios podem ter a habilidade de replicar informacoes ex-
tensivamente. Isto e usado para acrescentar disponibilidade e confiabilidade, enquanto
9Codigo aberto, podendo ser modificado e redistribuıdo sem a necessidade de pagamento de licenca.
13
Figura 2.5: Arvore de dados
reduzem o tempo de resposta. [Carter, 2003] [House, 2000] [Vitorio, 2005]
Os diretorios mostram-se versateis e adaptaveis a varios contextos de
aplicacoes, sendo projetados para diferentes tipos de servicos (tais como para uma aplicacao
especıfica, para sistemas operacionais de rede), para um proposito especıfico baseado em
padroes. Dentre as aplicacoes especıficas tem-se alguns exemplos como o IBM/Lotus
Notes e o Microsoft Exchange, ja para os sistemas operacionais de rede o eDirectory
da Novell (uma evolucao do NDS10) e o NIS11 da Sun. Um exemplo de utilizacao para
um proposito especıfico pode ser dado pelo DNS (Domain Name System)12 e para um
proposito geral baseado em padroes tem-se o LDAP. [LCC/UFMG, 2005] [Carter, 2003]
Um diretorio e uma implementacao baseada no princıpio cliente/servidor
para disponibilizar algum tipo de informacao, ou seja, e uma aplicacao que controla os
objetos e seus atributos dentro do mesmo. Este servico disponibiliza as informacoes con-
10Novell Directory Service e um dos primeiros servicos de diretorios amplamente empregado na
estruturacao/gerencia de redes.11Network Information Service e um servico de rede que trata das informacoes, fazendo com que estas
nao sejam duplicadas, possibilitando medir a consistencia dos dados, aumentando a flexibilidade e facili-
tando o trabalho de administracao.12DNS consiste em um esquema de gerenciamento de nomes, hierarquico e distribuıdo. [Kanies, 2001]
14
tidas no diretorio aos usuarios e a outras aplicacoes de um modo sistematico e estruturado.
[House, 2000] [Carter, 2003]
Quanto a sua abrangencia os servicos de diretorios podem ser locais,
atuando em uma maquina isolada, ou globais, atingindo um contexto mais amplo para
suas aplicacoes. Os servicos globais geralmente sao distribuıdos, ou seja, cada servidor e
responsavel por uma parte do servico disponibilizado. [House, 2000] [Carter, 2003]
Varias sao as formas de disponibilizar um servico de diretorios e en-
tre elas existem diferentes maneiras para tratar os tipos de informacoes para que estas
possam ser armazenadas. Com isso, este servico permite tratar os dados para definir as
formas com que as informacoes podem ser apresentadas, impedir acessos nao autorizados
e modificacoes nao permitidas. [Kanies, 2001]
Os tipos de informacao armazenados sao baseados em entradas de da-
dos, as quais sao constituıdas de um conjunto de atributos e apresentadas por um nome
distinto (DN - Distinguished Name). O DN foi especificado pela RFC 225313 para pos-
sibilitar entradas nao ambıguas, sendo que estas tem um tipo e um ou mais valores. Sao
geralmente usadas palavras mnemonicas14, como cn para nome comum(do ingles com-
mon name) , ou mail para enderecos de correio eletronico. [House, 2000]
Os servicos de diretorios proporcionam benefıcios aos seus usuarios,
como seguranca e integridade15. Alem disso, eles estabelecem padroes para as entradas
de dados fazendo com que uma identidade seja estabelecida. A Figura 2.6 exemplifica
a arquitetura de um servico de diretorio, onde uma determinada aplicacao e solicitada
atraves do protocolo TCP/IP, este protocolo acessa o diretorio retornando uma mensagem
a aplicacao cliente.
Dentro da mesma linha de raciocınio, o padrao X.500 determina todo
o processo de acesso a diretorios, desde as entradas dos dados na arvore hierarquica ate
13O RFC (Request For Comments) e uma recomendacao que define procedimentos para o bom funciona-
mento de servicos [RNP, 2005]14Palavras mnemonicas sao apelidos dados a determinadas palavras para referenciar um nome comum
ou expressar brevidade. [Anonimo, 2005b] [Takahashi, 2005]15Integridade e uma forma de seguranca que tem como objetivo garantir de que as informacoes no sejam
alteradas entre a estacao de origem e a estacao de destino. [Goldani, 2005]
15
Figura 2.6: Requisicao e resposta de dados
a resposta a requisicao. A interacao cliente/servidor e disponibilizada pelas definicoes
deste padrao, que atua fornecendo normas e protocolos para tornar possıvel este tipo de
acesso e servico.
Baseando-se nesses conceitos, torna-se importante um estudo mais de-
talhado deste padrao e das formas com que sao aplicadas suas definicoes. Simultanea-
mente ao X.500, protocolos como DAP e LDAP foram aprimorados melhorando o pro-
cesso de acesso e gerencia de diretorios.
2.2.1 X.500
O X.500 e um padrao que disponibiliza formas para realizar a conexao
e a gerencia de diretorios locais. Este tem como objetivo gerar um diretorio distribuıdo,
onde todos os servicos integrados terao acesso. [Filho, 2005] [Garcia, 2005]
Este padrao utiliza uma Base de Informacoes de Diretorio (BID - Di-
rectory Information Base16) onde ficam armazenadas as informacoes, que serao disponi-
bilizadas atraves de um servidor conhecido como Agente de Sistemas de Diretorios (DSA
16A BID e um conjunto de informacoes estruturadas no conceito de orientacao a objetos. Esta e composta
por entradas, chamadas de entradas de diretorio ou entradas de objeto, as quais representam os objetos do
mundo real, contendo as respectivas informacoes caracterısticas.
16
- Directory System Agent17). Este servidor interage com outros DSA, conforme a Figura
2.7, tornando possıvel realizar a comunicacao entre os usuarios/recursos. [Garcia, 2005]
[Kellermann, 2005]
Figura 2.7: Comunicacao entre usuarios/recursos
O X.500 oferece manutencao descentralizada, sendo responsavel ape-
nas pela parte de diretorios, um framework18 de informacao estruturada, um padrao que
disponibiliza a outras aplicacoes determinados tipos de informacoes e mecanismos de
procura, alem disso, suportando funcoes de gerenciamento das entradas de dados. Estas
entradas no diretorio X.500 descrevem um objeto, que tem um identificador unico cha-
mando DN, e consistem de uma colecao de atributos sendo que para uma pessoa, eles
podem ser: nome, endereco, e-mail, entre outros. [GSI, 2005]
Dentre suas funcionalidades, o X.500 serve para disponibilizar o acesso
de diretorios de forma que o usuario possa encontrar facilmente as informacoes deseja-
das, atraves de sua estrutura, organizacao sistematica e de suas formas de disponibilidade.
Esta facilidade surgiu devido ao detalhamento e a funcionalidade com que este padrao foi
17DSA e um servidor de dados onde as informacoes sao armazenadas. Estas informacoes ficam em uma
base de dados a qual e hierarquica e projetada para responder de uma forma mais rapida as questoes que
lhe sao colocadas.18Framework e um conjunto de objetos que colaboram com o objetivo de cumprir um conjunto de res-
ponsabilidades para uma aplicacao ou um domınio de um subsistema. [Guimaraes, 2005]
17
desenvolvido. Alem disso, cada dado armazenado tem um tipo especıfico e a identificacao
de um bloco e feita por um identificador, o qual e diferente para cada entrada, estas por sua
vez sao localizadas atraves de buscas na Arvore de Informacao de Diretorio (DIT - Direc-
tory Information Tree). A Figura 2.8 exemplifica esse conceito, pois em seu topo possui
um objeto raiz que tem como atributos ”Universidade”e em seguida e dividida em depar-
tamentos e cursos. Depois destes dados e onde sao armazenadas as informacoes sobre
pessoas ou objetos. Estas informacoes sao definidas atraves de regras pre-estabelecidas
e que encontram-se dentro das recomendacoes que definem o conceito e uso do X.500.
[House, 2000]
Figura 2.8: Arvore de Informacoes de Diretorio
Suas limitacoes espelham-se em seu alto grau de complexidade diante
das necessidades de implementacao, isto ocorre devido a forma com que fora estruturada
a informacao na sua base de dados. [GSI, 2005] No aspecto organizacional, o X.500
possui abrangencia global no domınio das redes inter-conectadas, sendo visto como uma
unica base de dados operando de forma distribuıda, atraves de um numero ilimitado de
sistemas computacionais.
Constata-se, pelas caracterısticas apresentadas, que o X.500 busca con-
centrar os dados de um diretorio em um so local e armazena-los de forma a organizar
e facilitar consultas de clientes. Esta forma de armazenamento auxilia a integracao das
informacoes e a mantem a diferenciacao e a autenticidade delas.
18
2.2.2 DAP
O Protocolo de Acesso a Diretorio (DAP), criado pela Universidade de
Michigan em 1988, foi definido com base no X.500 e serve para acessar servidores de
diretorios do tipo X.500. A forma de acesso, do cliente ao servidor que disponibiliza
o servico de diretorio, fundamenta-se em um protocolo baseado no modelo de referencia
OSI. Porem a pilha de protocolo OSI mostrou-se complexa demais para ser implementada
em um protocolo, devido a quantidade significativa de recursos necessarios do sistema e
mecanismos de suporte para superar a complexidade do protocolo, inviabilizando o uso
do DAP em sistemas computacionais sem muitos recursos. [GSI, 2005] [Pohlman, 2003]
O DAP cria um padrao para a comunicacao entre cliente/servidor que
acontece em um diretorio. Isto esta definido para ocorrer atraves do uso de um protocolo
complexo, pois tenta envolver sistemas distribuıdos em geral e possuı alto custo compu-
tacional. Os equipamentos existentes na epoca de seu surgimento nao possuıam recursos
suficientes a ponto de obter bom desempenho com o seu uso. [GSI, 2005]
Devido as dificuldades encontradas para a implementacao do protocolo
DAP, varias melhorias foram estudadas e varias mudancas foram sugeridas. Baseando-se
nessa problematica foi desenvolvido uma versao mais leve do protocolo, chamada LDAP.
Esta e baseada nos componentes do DAP, ou seja: trabalha com um menor custo compu-
tacional aumentando a funcionalidade e diminuindo-se a complexidade, atraves do em-
prego de tecnologias menos onerosas computacionalmente. [Kanies, 2001] Deste modo a
criacao do LDAP busca melhorar a integracao das informacoes e tornar o protocolo final
mais leve e de facil acesso/implementacao.
2.2.3 LDAP
O LDAP e um protocolo que define um servico e formas de acesso em
diretorios, baseado numa simplificacao do DAP que possibilita viabilizar a implementacao
do conceito de diretorios (estabelecido pelo X.500) de modo que possa ser empregado em
diversos sistemas computacionais. Este protocolo atua de forma que um servidor LDAP
fornece o servico de diretorio e os clientes LDAP utilizam para acessar entradas e atri-
19
butos, de modo simplificado, facilitando o seu uso tanto por parte dos usuarios como de
aplicacoes. Essas caracterısticas estao tornando-o como servico de diretorio padrao da
Internet devido ao fato de ser capaz de prover acesso aberto aos servicos de diretorios
da Intranet/Internet, bem como de integrar diretorios heterogeneos. [Komarinski, 2005]
[Carter, 2003] [Kanies, 2001]
As aplicacoes deste protocolo podem ser utilizadas para localizar (tam-
bem gerenciar) usuarios e recursos na rede ou para realizar autenticacao e seguranca. Sao
exemplos destas aplicacoes as listas de telefones, informacoes de contatos dos clientes,
informacoes de infra-estrutura, como mapas de NIS, configuracoes de pacotes de soft-
ware, certificados digitais e chaves seguras. [Martins, 2005]
A especificacao do LDAP foi publicada primeiramente com a RFC 1487
(X.500 Lightweight Directory Access Protocol) em 1993. Esta RFC sugere uma conexao
do X.500 com o LDAP, especificando aplicacoes simples para a gerencia e acesso in-
terativo de leitura e gravacao num diretorio, buscando ser um complemento ao DAP.
Estabeleceu-se assim uma marco inicial, sendo que essa especificacao ficou sendo co-
nhecida como a primeira versao oficial do LDAP. [Archives, 2005] [Kanies, 2001]
Desde entao o LDAP vem sendo aprimorado, gerando novas RFC’s e
consequentemente novas versoes. A segunda versao deste protocolo foi especificada pela
RFC 1777 (Lightweight Directory Access Protocol) e a terceira e definida por um conjunto
de RFC’s, entre 2251 a 2256. Sendo assim e relevante destacar a finalidade de algumas
dessas especificacoes [Archives, 2005]:
• RFC 1558, (A String Representation of LDAP Search Filters): Define a representa-
cao dos filtros de busca para o protocolo LDAP;
• RFC 1777, (Lightweight Directory Access Protocol): Especifica o conceito e fina-
lidade do LDAP;
• RFC 1778, (The String Representation of Standard Attribute Syntaxes): Representa
a forma com que devem ser descritos os atributos;
• RFC 1959, (An LDAP URL Format): Define um formato de URL para o LDAP;
20
• RFC 2251-2256: Representam as RFC’s que deram origem as modificacoes que
levaram a terceira versao do LDAP;
• RFC 2829, (Authentication Methods for LDAP): Define os metodos de autenticacao
empregados para o LDAP;
• RFC 2830, (Lightweight Directory Access Protocol (v3): Extension for Transport
Layer Security): Busca garantir a seguranca na camada de transporte;
• RFC 3377, (Lightweight Directory Access Protocol (v3): Technical Specification):
Especificacao tecnica da terceira versao do LDAP, definido as mudancas, compati-
bilidade e formas de implemetacao.
Baseando-se nestas especificacoes, varios padroes, protocolos e servicos
foram criados e entre estes muitas diferencas e melhorias foram estabelecidas. As tres
versoes do LDAP, uma apos a outra, sao exemplos desses aperfeicoamentos que buscam
tornar o LDAP um protocolo acessıvel, flexıvel e atendendo as necessidades crescentes
de diretorios.
A vantagem mais significativa do LDAP, em relacao ao DAP, e que
ele funciona utilizando a pilha de protocolo TCP/IP (que e amplamente empregada e
difundida, baseado no modelo DARPA) ao inves de requerer um novo protocolo baseado
no modelo OSI como o DAP especificava. Conforme mostrado na Figura 2.9 o LDAP
e um protocolo implementado na camada de aplicacao do modelo TCP/IP, facilitando a
comunicacao entre o cliente e o servidor de diretorio. Por outro lado o DAP, baseado no
modelo OSI, requer uma complexidade de implementacao do protocolo muito difıcil de
ser realizada e nao amplamente empregado mundialmente. [Voglmaier, 2004]
E atraves do modelo DARPA que o LDAP realiza a troca de mensagens.
A informacao transmitida e uma mensagem contida em um envelope de mensagem, o qual
tem um formato bem definido e e chamado de Unidade de Dados do Protocolo (PDU -
Protocol Data Unit). O PDU deve conter duas partes de informacao, o identificador da
mensagem, que faz uma sincronizacao entre a solicitacao e a resposta, e uma operacao,
que pode ser um pedido do cliente ao servidor ou uma resposta emitida. [Voglmaier, 2004]
21
Figura 2.9: Comunicacao cliente/servidor baseada no LDAP como intermediario para requisicoesDAP
Apos o cliente LDAP emitir um pedido ao servidor, este executa uma
ou mais operacoes, como especificado no pedido. Para uma transmissao bem sucedida,
o servidor emite os resultados. Ja para apresentar um erro, um aviso e emitido para o
cliente. Cada mensagem de LDAP, pedidos e respostas, contem um ID, um codigo de
operacao e os dados. [Voglmaier, 2004]
O pedido da busca pode ter resultados como os dados da propria busca,
uma mensagem que indique a execucao da pergunta ou uma referencia que indica onde
os dados pedidos poderiam ser encontrados. Para exemplificar este tipo de comunicacao
tem-se a Figura 2.10, onde sao relatadas a solicitacao e a resposta de uma conexao feita
pelo cliente ao servidor, de um pedido de busca e da desativacao da conexao realizada.
[Voglmaier, 2004]
Figura 2.10: Comunicacao cliente/servidor LDAP atraves de operacoes
22
Como resultado da comunicacao cliente/servidor, observado na Figura
2.10, pode-se dizer que as informacoes do diretorio sao armazenadas em forma de arvore
ou hierarquicamente, como o DNS e estruturas de diretorios de arquivos. Esse aspecto
facilita as solicitacoes especıficas a um ramo, a implementacao de seguranca em ramos
diferentes da arvore e o controle da utilizacao de banda da rede. [Martins, 2005] Os
dados que serao armazenados na arvore sao denominados de entradas e estes passam de
objetos do mundo real para moldes das estruturas de dados de um diretorio, sendo que
cada entrada tem um nome e um identificador original do objeto (DN).
O processo de autenticacao e utilizado para estabelecer os privilegios
do cliente para cada aplicacao. Para realizar a autenticacao de forma adequada deve-se
entender quais os tipos existentes [Carter, 2003]:
• Autenticacao Anonima: e o processo de interacao com o diretorio usando um
DN e uma senha vazios. Este tipo de autenticacao e usado frequentemente por
aplicacoes do cliente (como por exemplo, os clientes de e-mail procurando um li-
vro de endereco).
• Autenticacao Simples: o login19 em forma de um DN e emitido com uma senha para
o servidor de LDAP. O usuario combina esta senha com o valor do login, ou com
algum outro atributo predefinido que e contido na entrada para o DN especificado.
• Autenticacao Simples sobre SSL20/TLS21: o LDAP utiliza uma camada de trans-
porte que realiza a cifragem dos dados (por SSL/TLS) para garantir que ao informar
um login e uma senha, o usuario tera seus dados transmitidos com maior seguranca.
O uso do LDAP com SSL suporta muitos servidores, devido a popularidade e am-
19Login e a identificacao pessoal de cada usuario no sistema, tipicamente empregando um campo de
usuario e outro de senha.20Secure Socket Layer e um protocolo de seguranca desenvolvido pela Netscape Communications que
tem por finalidade compensar a falta de protecao de dados da Internet atraves de uma camada de codificacao
dos dados que precede a camada ser protegida, podendo ser usado em varios servicos.21Transport Layer Security e um protocolo que fornece privacidade e integridade de comunicacao.
Este permite que aplicacoes cliente/servidor comuniquem-se prevenindo a escuta e/ou modificacao de
comunicacoes privadas sem autorizacao.
23
plo emprego de servico baseados nessa arquitetura (sendo o servico TCP/HTTPS22
o principal)
• Autenticacao Simples e Camada de Seguranca (SASL - Simple Authentication and
Security Layer): SASL e um esquema de seguranca definido pela RFC 2222 que
pode ser usado para adicionar mecanismos de autenticacao a protocolos como LDAP.
Permite que o servidor e o usuario negociem mecanismos de autenticacao antes de
trasmitirem algumas credenciais do usuario.
Baseando-se nessas formas de autenticacao os desenvolvedores do pro-
tocolo LDAP buscaram integrar a comunicacao do servidor com seus clientes de uma
forma segura. Esta seguranca abrange varias formas e mecanismos, os quais tendem a ser
sincronizados e trabalhar de forma a atender requisitos a um alto nıvel funcional.
Com isso, foram implementados quatro modelos para a utilizacao do
LDAP, os quais abrangem pontos de vista diferentes. Entre eles estao [Voglmaier, 2004]
[LCC/UFMG, 2005]:
• Modelo de Informacao: descreve as unidades basicas usadas pelo LDAP para ar-
mazenar informacoes.
• Modelo de Nome: descreve as estruturas do diretorio.
• Modelo Funcional: define as funcoes que o LDAP oferece para acessar, manter e
controlar o diretorio.
• Modelo de Seguranca: descreve os processos de autenticacao e autorizacao.
Dentre todos os modelos existentes de LDAP, varias caracterısticas sao
definidas e seu funcionamento especificado. Em conjunto a eles, RFC’s foram criadas
objetivando detalhar as informacoes de um diretorio, a forma com que estas sao acessadas
e gerenciadas, a camada onde o protocolo atual, a seguranca necessaria para autenticacao
22O HTTPS e empregado para cifrar os dados transmitidos em conexoes HTTP, sendo amplamnete em-
pregado por empresa que fazem comercio eletronico na Internet.
24
e para autorizacao do acesso de usuarios, entre outras. Isso fez com que o uso do LDAP se
tornasse mais acessıvel, gerando um aumento significativo de aplicacoes que o utilizam,
afim de gerenciar e integrar os dados de diretorios.
Devido ao aumento significativo do uso do LDAP formas de transmitir
e armazenar informacoes com maior seguranca, dentro de diretorios, tornou-se essencial.
Baseando-se nisto, maneiras de controlar o acesso e realizar autenticacao foram implan-
tadas e aperfeicoadas.
2.3 Seguranca
A seguranca das informacoes em diretorios e essencial, pois previne
contra acessos nao autorizados a determinados tipos de aplicacoes e dos proprios recur-
sos disponibilizados pelo servico. Para buscar uma seguranca em um nıvel aceitavel, e
assim garantir que as funcionalidades dos recursos nao sejam prejudicadas, e necessario
compreender alguns conceitos basicos envolvidos.
Um conceito essencial e o de vulnerabilidade, que refere-se a algum
tipo de falha(tecnica ou nao-tecnica) que possibilita a realizacao de acessos nao autoriza-
dos, podendo ser oriunda de diversos fatores (a nao atualizacao do sistema operacional,
configuracoes incorretas e falta de antivırus, sao os mais comuns). Existindo a vulnerabi-
lidade tem-se a possibilidade dessa ser explorada, implicando no que chama-se ameaca.
A relacao entre as vulnerabilidades existentes e as ameacas possıveis implicam no risco
associado aos recursos vulneraveis. A falta de seguranca proporciona riscos indesejaveis
a rede, dentre os quais relata-se o acesso nao autorizado, manipulacao dos dados e a
utilizacao nao autorizada de computadores e seus recursos, o que se pode chamar de
ameacas. Diante disso, pode-se dizer que risco e a possibilidade existente de que pessoas
nao autorizadas manipulem os dados de uma rede, comprometendo assim as atividades
de uma organizacao. [Carneiro, 2005] [Soares, 1995] [Schneier, 2001]
Devido ao desenvolvimento e a necessidade de protecao das informacoes
dentro de uma rede criou-se o termo seguranca em redes de computadores. Este direciona
seus conceitos para tudo o que e realizado com o objetivo de diminuir as vulnerabilidades
25
e ameacas existentes em bens (coisas de valor) ou recursos. [Schneier, 2001]
Diante destas informacoes pode-se concluir que a protecao contra o
acesso e manipulacao das informacoes ou do computador de uma rede faz com que a
quantidade de vulnerabilidades diminua. Com isso, as ameacas existentes como, por
exemplo, destruicao, modificacao, roubo, remocao, revelacao, interrupcao ou perda das
informacoes e dos recursos, devem ser minimizadas a nıveis toleraveis23.
A protecao de uma rede pode ser feita atraves de uma Polıtica de Se-
guranca. Este termo nada mais e do que uma combinacao de regras, leis e a pratica des-
tas, em busca de realizar a gerencia e protecao dos dados e recursos de uma instituicao.
[Carneiro, 2005] Para formular uma polıtica seguranca e basicamente necessario identifi-
car as falhas na seguranca e estabelecer o que e e o que nao e possıvel durante a operacao
de um sistema na rede, o que e chamado de analise de riscos. Com isso, deve-se estabele-
cer objetivos e um plano para executa-los. [Soares, 1995]
O objetivo da analise de riscos e identificar e especificar os riscos de
seguranca que o usuario/recurso esta exposto, de acordo com as suas necessidades. Deve-
se levar em conta o impacto que uma falha na seguranca ira causar perda de confidenciali-
dade, integridade ou disponibilidade da informacao. E por isso que e necessario conhecer
os respectivos conceitos [Semola, 2003] [NBR ISO/IEC 17799, 2001]:
• Confidencialidade: significa proteger a informacao, para que apenas pessoas auto-
rizadas tenham acesso a ela.
• Integridade: e proteger a informacao de modificacoes sem permissao.
• Disponibilidade: e o usuario autorizado ter as informacoes acessıveis e prontas para
o uso.
• Autenticidade: significa garantir que a identidade da entidade com a qual se esta
comunicando corresponde aquela desejada.
Baseando-se nestas definicoes, e nas necessidades de seguranca, o LDAP
busca garantir a integridade dos dados, controlar o acesso aos diretorios e proteger essas
23Garantir cem por cento de seguranca e impossıvel. [Schneier, 2001] [Semola, 2003]
26
informacoes. Para que estes fatores sejam tratados com determinado grau de seguranca
e necessario ter controle sobre autorizacoes e autenticacoes. Estes controles devem ser
estabelecidos antes que um usuario possa ter acesso ao servidor de diretorios.
Conforme fora descrito, na sub-secao 2.2.3, existem varias formas de
conectar-se ao servidor, uma delas e realizar a conexao sem a necessidade de fornecer
uma identidade, este tipo e chamado de Autenticacao Anonima. Alem disso, existem
a autenticacao onde o usuario informa um login e uma senha e a que o acesso e reali-
zado atraves de mecanismos certificados. Cada uma dessas formas possui suas particu-
laridades, e fornece um nıvel de protecao que esta atrelado ao nıvel de risco do tipo de
autenticacao. [Carter, 2003]
A forma de realizar a autenticacao atraves de certificados garante que a
identidade de um determinado usuario seja verdadeira, isso faz com que o servidor tenha
certeza de que o cliente e realmente quem diz ser. Apos ser reconhecido pelo servidor, o
usuario recebera seus direitos de acesso que foram previamente estabelecidos. Este entao
pode realizar solicitacoes e salvar novas informacoes com as limitacoes que dependem do
nıvel do acesso concedido. [Pohlman, 2003]
A implantacao adequada desses requisitos de seguranca em modelos,
padroes, protocolos e aplicacoes trazem como benefıcios um nıvel de seguranca mais
adequado a realidade do ambiente aonde se encontra inserido. Existem varios exemplos
de empresas que tem esses servicos de diretorios e buscam garantir a integridade e a
autenticidade das informacoes, mantendo o diretorio seguro.
2.4 Conclusao
Neste capıtulo foram estudados e analisados os principais conceitos e
o historico do LDAP, assim como a necessidade do surgimento de servicos de diretorio.
Estes servicos motivaram a evolucao e o desenvolvimento de diversos componentes ne-
cessarios (para o funcionamento efetivo com um performance aceitavel) como: proto-
colos, padroes, modelos e aplicacoes desta area. A aplicacao dos servicos de diretorios
somente tornou-se mais difundida/utilizada a partir da necessidade de controle de acesso
27
e de gerenciamento das informacoes dentro de um esquema baseado em diretorios. Tais
informacoes podem ser definidas como dados de pessoas, organizacoes, produtos ou e-
mail.
O padrao X.500 contribuiu na definicao de uma serie de especificacoes
para o uso de diretorios, entre elas formas de adicionar, modificar, pesquisar e excluir as
informacoes. Para realizar um trabalho mutuo ao X.500, o DAP foi desenvolvido. Diver-
gindo do DAP o LDAP e uma versao mais leve que facilita a aquisicao e a manutencao
de servicos de diretorios, pois este tem menos especificacoes e torna possıvel o uso em
ambientes com limitados recursos computacionais.
Alem disso, o LDAP veio a disponibilizar diversos metodos de con-
trole de acesso, proporcionando autenticacao variada a fim de garantir a integridade das
informacoes. Deste modo, varias maneiras de buscar a seguranca e gerenciar o acesso
foram especificadas e aprimoradas, tornando a utilizacao dos servicos de diretorios mais
segura e consequentemente mais viavel.
Capıtulo 3
LDAP
Os servicos de diretorios surgiram devido a necessidade da integracao
de informacoes contidas em diferentes tipos de sistemas. Tais dados eram armazenados
em diretorios individuais para cada sistema. Com a integracao destas informacoes houve
uma reducao consideravel das redundancias existentes ate entao, isso viabilizou estudos,
criacao de padroes, modelos e protocolos e aperfeicoamento destes.
3.1 Definicao
LDAP e essencialmente um conjunto de protocolos e especificacoes que
servem para acessar certos tipos de dados, ou seja, especificam formas de acesso, busca,
modificacoes, exclusoes e insercoes de informacoes dentro de um diretorio. Tal acesso
ocorre entre clientes que desejam obter/submeter informacoes de um diretorio, controlado
por uma aplicacao servidora, aonde estas encontra-se armazenadas. [Voglmaier, 2004]
Alem disso, o LDAP tambem e considerado leve porque omite muitas operacoes especi-
ficadas pelo X.500, com isso, as definicoes estabelecidas sobre servicos de diretorios sao
mensuradas e aproveitadas baseando-se em seu grau de usabilidade.
Baseando-se nestas definicoes, pode-se dizer que o LDAP proporci-
ona uma maior disponibilidade e performance as informacoes de um diretorio, devido as
simplificacoes das formas de utilizacao das especificacoes propostas pelo X.500. A forma
29
com que o LDAP foi projetado, tem como base uma nova estruturacao e a organizacao do
seu funcionamento, eliminando camadas de comunicacao e tipos de dados armazenados
de modo a torna-los mais flexıveis e portaveis.
Alem disso, o LDAP proporcionar a integracao de acessos, disponibili-
zando ao usuario uma unica identidade digital. Isso facilita a memorizacao, por ser um
unico login para varios sistemas, e elimina as redundancias de informacoes dentro de um
diretorio. Diante destas formulacoes e embasamentos torna-se necessario um estudo mais
amplo das funcionalidades deste protocolo, de seus servicos e aplicacoes.
3.2 Arquitetura/Funcionamento
O LDAP possui um padrao que especifica a comunicacao cliente/servi-
dor, isso significa que ele nao e um software mas sim a implementacao de um meio de
comunicacao entre eles. Devido a isto, tem-se varias ferramentas que interpretam suas
especificacoes e realizam a execucao destas. [Carter, 2003]
Sendo projetado para ser uma versao resumida do DAP, e usado em con-
junto com diretorios de X.500, foi definido inicialmente para intermediar a comunicacao
entre um cliente e um servidor que abrangesse todas as especificacoes do Modelo OSI.
Devido ao fato de isso mostrar-se por demais complexo (e tambem questionavel quanto
a sua utilidade efetiva), ele foi simplificado para realizar a comunicacao cliente/servidor
baseada no Modelo DARPA, onde as mensagens sao transmitidas sobre a camada de
aplicacao TCP/IP. A diferente abordagem de implementacao da pilha de protocolos origi-
nou-se essencialmente devido a equipe que densenvolveu o TCP/IP (DARPA) empregar
uma abordagem que exigia a comprovacao dos conceitos atraves de implementacoes, en-
quanto que a ISO (responsavel pelo desenvolvimento do OSI) preocupava-se mais com a
abordagem conceitual, resultando que quando ambas as equipes terminaram as suas pes-
quisas a DARPA ja possuıa um protocolo operacional enquanto a outra so dispunha de
um modelo referencial (o qual nao havia comprovacao se sua implementacao era viavel
ou nao). As diferencas entre as duas abordagens de desenvolvimento de protocolo podem
ser percebidas na Figura 3.1. [Carter, 2003]
30
Figura 3.1: Representacao dos modelos OSI e DARPA
O fato de empregar o Modelo DARPA, ao inves do Modelo OSI espe-
cificado no DAP, fez com que a implementacao do LDAP fosse viabilizada, pois mui-
tas caracterısticas definidas no DAP, raramente utilizadas, foram eliminadas. Com base
nesta simplificacao, o LDAP adquiriu vantagens, fez com que sua popularidade e aces-
sibilidade se tornassem amplas e que a comunicacao cliente/servidor perdesse requisitos
desnecessarios anteriormente estabelecidos.
Nesta forma de comunicacao estabelecida pelo LDAP, a unidade basica
de informacao e transmitida atraves de um envelope de mensagem, tambem conhecido
como Unidade de Dados do Protocolo (PDU), conforme a Figura 3.2. Este envelope tem
um formato bem definido e permite que a comunicacao cliente/servidor seja realizada, em
forma de mensagens, onde solicitacoes e respostas sao enviadas. Para realizar de forma
adequada esta troca de mensagens, a PDU deve conter dois pedacos de informacao: um
identificador de mensagem e uma operacao. [Voglmaier, 2004]:
Figura 3.2: Representacao do PDU e de seu formato
Diante deste formato, pode-se dizer que ambas as partes sao essenciais,
visto que, o identificador garante que os pedidos e as respostas sejam sincronizados e que
31
uma resposta seja nomeada a cada pedido, vinda do servidor ou do cliente. Ja a operacao
define o que foi solicitado ao servidor de LDAP. A Tabela 3.1 apresenta algumas das
possıveis operacoes disponibilizadas. [Voglmaier, 2004]
Tabela 3.1: Operacoes LDAP
Operacao Descricao
bindRequest Solicitacao de conexaobindResponse Resposta a solicitacao de conexaounbindRequest Requisicao para desconexaosearchRequest Solicitacao de buscasearchResEntry Entrada resultante da buscasearchResDone Resultado da busca finalizadosearchResRef Referencia do resultado da busca
modifyRequest Pedido de modificacao de informacoesmodifyResponse Resposta a modificacao
addRequest Solicitacao de adicao de dadosaddResponse Resposta a solicitacao de adicaodelRequest Requisicao para apagar informacoes
delResponse Resposta a requisicao de deletarmodDNRequest Solicitacao de modificacao de DN
modDNResponse Resposta a solicitacao de modificar um DNabandonRequest Requisicao de abandono
extendedReq Solicitacao de estencaoextendedResponse Resposta ao pedido de estencao
O cliente faz um pedido ao servidor LDAP, conforme a Tabela 3.1, e
este por sua vez executa tantas operacoes necessarias para realizar a solicitacao. Apos o
processamento o servidor envia os resultados para representar o sucesso ou uma mensa-
gem para indicar a falha na execucao do pedido. Diante disto, pode-se concluir que para
todos o pedidos existe uma solicitacao e normalmente uma resposta, porem isso podera
nao ocorrer para a operacao unbind (sendo que esta realiza a desconexao e nao requer ne-
nhuma resposta). Outro ponto relevante de ser comentado e que ao usuario solicitar uma
busca, ele pode receber tres tipos de resultados, como os dados resultantes do pedido, uma
mensagem que indica a execucao ou uma referencia que indique onde as informacoes re-
queridas podem ser achadas. [Voglmaier, 2004]
Analisando o funcionamento da operacao entre o pedido e a resposta
constata-se que o LDAP estabelece uma comunicacao comum entre cliente/servidor, sendo
que esta e representada por envio e recebimento de mensagens. O PDU realiza esta trans-
32
missao atraves de um envelope que contem um identificador e uma operacao, isso facilita
ao servidor enviar um determinado tipo de resposta a solicitacao do cliente. Com isso,
a comunicacao torna-se mais detalhada, no sentido de que qualquer solicitacao recebe
uma mensagem para avisar se a operacao ocorreu como esperado ou se algum erro foi
identificado.
Este detalhamento e a necessidade de gerar novas alteracoes na especifi-
cacao do LDAP deram origem a duas novas versoes. Entretanto as tres versoes existentes
buscam, cada vez mais, aprimorar o acesso e a gerencia de diretorios, originando diversas
aplicacoes com este objetivo.
3.2.1 Versoes
A maior parte do desenvolvimento do LDAP foi coordenado pela Uni-
versidade de Michigan, sendo seus primeiros protocolos estao definidos na RFC 1202
- Directory Assistance Service e na RFC 1249 - DIXIE Protocol Specification. Na RFC
1202 encontra-se a definicao de um mecanismo pelo qual um usuario pode acessar uma in-
terface DAP usando uma conexao de TCP/IP. Ja a RFC 1249, especifica uma simplificacao
do transporte e de protocolos de apresentacao para a utilizacao de servicos de diretorios.
[Archives, 2005]
A primeira especificacao de LDAP foi na RFC 1487 - X.500 Lightweight
Directory Access Protocol, que apos ser aprimorada, melhor estruturada e simplificada foi
substituıda pela RFC 1777, Lightweight Directory Access Protocol. Esta RFC tambem e
conhecida como a que deu origem a segunda versao do LDAP. [Archives, 2005]
A terceira versao fornece/define um modelo mais simples para os pro-
gramadores e administradores. Esta definiu as operacoes de uma forma sucinta e eliminou
as caracterısticas raramente usadas. Com isso, o objetivo era de aumentar o uso do LDAP
em aplicacoes e fazer isto de uma forma facil.
Baseando-se na origem destas, consideraveis diferencas entre a segunda
e a terceira versao foram apresentadas, relatando a melhoria de funcionalidades existente
entre ambas. Principais caracterısticas da terceira versao [Voglmaier, 2004]:
33
• Muitos elementos de dados podem ser codificados como strings ordinarias.
• Indicacoes podem ser retornadas. Caso um servidor de diretorio nao contenha as
informacoes pedidas, este pode indicar outro servidor de diretorio que as tenha.
• Mecanismos SASL podem ser usados com LDAP para prover servicos de seguranca.
• Foram internacionalizados valores de atributo e distintos nomes com uso fixo da
quantidade de carateres (10,646 carateres).
• O protocolo pode ser estendido para suportar novas operacoes e podem ser usados
controles para estender operacoes existentes.
• A descricao das estruturas de dados de um diretorio e publicada no diretorio para
ser utilizada pelos clientes.
A terceira versao do LDAP e a versao atual e define varias caracterısticas
adicionais que nao eram contempladas na segunda versao. Sua especificacao e mais clara
e detalhada, tornando este protocolo mais divulgado e utilizado em diferentes aplicacoes.
Alem disso, a terceira versao de LDAP disponibiliza maior protecao as informacoes de
um diretorio, implementando recursos mais seguros para autenticacao e autorizacao de
usuarios.
3.2.2 Aplicacoes
Devido ao fato de que o LDAP realizar a comunicacao cliente/servidor
ele nao define como ou onde os dados sao armazenados. A escolha de onde as informacoes
ficarao e independente da implementacao sendo que o repositorio pode ser implementado
por diversas aplicacoes, como o OpenLDAP, o Netscape, o Microsoft AD, o IBM Tivoli
Directory Server, o Novell eDirectory e o AE Slapd. Estas aplicacoes sao baseadas nos
requisitos da implementacao do LDAP, feitos pela Universidade de Michigan.
34
3.2.2.1 OpenLDAP
O OpenLDAP consiste em uma implementacao para realizar o acesso e
a gerencia das informacoes dentro de um diretorio. Seu projeto e gerenciado pela Open-
LDAP Foundation, sendo que este descreve fundamentos do LDAP como DIT’s, esque-
mas, indicacoes, classes de objetos, ligacao, seguranca, entre outros. [MacIsaac, 2005]
Sua implementacao baseia-se em codigo livre, pois o OpenLDAP foi
desenvolvido para trabalhar em ambientes que envolvam os usuarios dos S.O. GNU/Linux,
MS-Windows NT, AIX, BSD e Solaris. O OpenLDAP foi implementado na segunda
versao do LDAP, porem so se tornou estavel e foi liberado na terceira versao, fornecendo
suporte para replicacao de servidores e integracao com demais servidores LDAP de outras
plataformas. [Marshall, 2005]
A implementacao do OpenLDAP prove de muitas funcionalidades, co-
mo suporte a SSL/TLS, autenticacao com SASL, integracao com Kerberos, conceitos do
padrao X.500, controle de acesso pelo usuario ou grupo e apoio a LDBM (Lightweight
Database Management) e SQL (Structured Query Language). [Marshall, 2005] Com
base nestas utilidades, pode-se dizer que o OpenLDAP foi desenvolvido para garantir a
seguranca, autenticacao, autorizacao e acesso, buscando possibilitar aos usuarios uma co-
nexao com o servidor LDAP e os servicos previamente estabelecidos pelo padrao X.500.
O Netscape utiliza uma administracao leve da base de dados do sistema
(LDBM). Esta base de dados e denominada como um banco de dados embutido, o qual
evita o consumo de recursos e atividades desnecessarias. Ja o OpenLDAP oferece uma
diversidade de escolhas para este tipo de armazenamento, isto inclui varias bases de dados
embutidas ou a criacao de sua propria base. Este ainda possibilita o acesso a um SQL,
isto lhe permite usar um RDBMS1(Relational Database Management System). Assim
o OpenLDAP permite combinar o LDAP com um sistema de base de dados relacional.
Entretanto, um RDBMS e um servidor de endereco de diretorio tem propositos diferentes.
Estas diferencas podem ser [Voglmaier, 2004]:
• Um servidor de diretorios nao reconhece uma transacao. O proposito de uma
1RDBMS e um sistema que realiza a gerencia de uma base de dados relacional.
35
transacao e garantir consistencia de dados. Um RDBMS oferece apoio transaci-
onal, porem o LDAP nao garante tal integridade de dados.
• O servidor de diretorio nao oferece suporte entre diferentes dados.
• Um servidor de diretorio nao reconhece as utilidades de realizar a construcao de
relatorios.
• O servidor de diretorio tem um mecanismo complicado de replicacao. Este tambem
apoia um modelo multi-mestres alem do modelo de replicacao mestre-escravo.
• Os diretorios surgiram com o intuıto de serem utilizados para realizar a leitura dos
dados e nao para fazer atualizacoes. Aplicacoes que atualizam varios dados por
minuto nao sao candidata para servicos de diretorios.
• Os diretorios sao organizados de modo hierarquico. Esta forma de armazenar
informacoes ajuda a evitar redundancias de dados.
• Os diretorios confiam em padroes abertos que garantem a interoperabilidade de
aplicacoes diferentes em distintas plataformas.
• Na utilizacao de diretorios os usuarios tem acesso a funcoes como distribuicao de
dados e replicacao destes dentro do software.
• Os diretorios oferecem uma forma leve de conectar um repositorio, trabalhar com
os dados e fechar a conexao. Um RDBMS necessita de mais tempo para estabelecer
uma conexao. Porem, apos estabelecer conexao o RDBMS oferece uma quantidade
maior de servicos.
Estes fatores e a forma com que e combinado o LDAP com um RDBMS,
influenciam na escolha, na performance e nas especificacoes das aplicacoes existentes.
Estas aplicacoes servem como uma interface a utilizacao do protocolo e alem destas mui-
tas outras podem ser integradas ao LDAP e podem auxiliar os usuarios a utilizacao dos
servicos de diretorios.
36
3.2.2.2 Active Directory
O Active Directory tem o objetivo criar e manipular informacoes de
um diretorio, fornecendo funcionalidades de servicos de diretorios incluindo ferramen-
tas de organizacao, gerencia, controle de acessos e permissoes. Este foi desenvolvido
pela Microsoft para ser integrado a versao MS-Windows 2000 e suas versoes posteriores.
[Brito, 2005] [Quirino, 2005]
Diante de suas funcionalidades o AD centraliza os recursos de rede, fa-
zendo com que sua topologia torne-se transparente, Figura 3.3. Isto possibilita, ao usuario,
obter qualquer recurso e acesso sem saber onde o recurso esta ou como ele esta fisicamente
conectado a rede. [Brito, 2005]
Figura 3.3: Topologia de rede transparente para usuarios
Na Figura 3.3 sao representados varios tipos de recursos, aplicacoes
37
e usuarios os quais de uma forma geral sao centralizados aos servicos do AD. Todas
os recursos como usuarios, clientes, servidores, dispositivos, aplicacoes, aplicativos e
servicos de diretorios sao representados com algumas caracterısticas as quais fazem com
que eles parecam um unico recurso, ou seja, nao e necessario saber onde estes encontram-
se ou como funcionam.
Com base nas suas caracterısticas de implementacao, o AD pode ser
utilizado com qualquer aplicativo que esteja previamente autenticado no controlador de
domınio, seja capaz de utilizar o protocolo LDAP e conheca previamente o esquema do
diretorio, o que teoricamente o torna portavel a qualquer plataforma. Porem, alem de ser
proprietario, exige licenciamento. [Quirino, 2005] [Brito, 2005]
A organizacao do AD e feita em secoes e subsecoes e isto permite o
armazenamento de um grande numero de objetos. Com isso, os recursos podem ser ex-
pandidos conforme o crescimento da organizacao, mantendo o gerenciamento unico com
um servidor e centenas de objetos ou entao com milhares de servidores e milhoes de
objetos. [Quirino, 2005] [Brito, 2005]
No AD os recursos de rede, como usuarios, grupos, computadores, im-
pressoras, servidores, domınios e sıtios na rede, sao os objetos e cada objeto possui suas
caracterısticas especıficas, as quais sao utilizadas para agrega-los em unidades organi-
zacionais distintas. Estes objetos sao armazenados em um banco de dados distribuıdo,
possibilitando a gerencia de um unico administrador. [Quirino, 2005] [Brito, 2005]
Para realizar este gerenciamento, foram criadas unidades organizacio-
nais, que reunem objetos com atributos comuns, permitindo que polıticas e delegacoes
sejam aplicadas a todos os elementos pertencentes aquele agrupamento. Alem disso, um
objeto pode pertencer a diversas unidades organizacionais, adquirindo caracterısticas dos
grupos aos quais participa. [Quirino, 2005] [Brito, 2005]
No AD o esquema contem as definicoes dos objetos, de forma que estes
devem obedecer as mesmas regras. Existem dois tipos de definicoes no esquema , a classe
de objetos e os atributos. As classes de objetos descrevem os objetos que podem ser cria-
dos em um diretorio e definem colecoes de atributos. Estes atributos sao definidos apenas
uma vez e podem ser utilizados em varias classes de objetos. Este esquema e armazenado
38
no banco de dados relacional, possibilitando assim a disponibilidade dinamica aos aplica-
tivos de usuario, onde outros aplicativos de usuario podem ler o esquema para descobrir
que objetos e propriedades estao disponıveis para utilizacao, e a atualizacao dinamica,
onde um aplicativo pode estender o esquema adicionando novos atributos e classes de
objetos.
A implementacao do AD consiste em um servico constituıdo de uma
serie de composicoes de aplicativos escolhidos pela Microsoft. Como o OpenLDAP e
o Netscape, ele e uma aplicacao que serve de interface entre cliente e servidor. Estas
implementacoes tem atribuıdas, em suas funcionalidades, as definicoes de servicos de
diretorios, entre eles a forma de acesso e gerenciamento das informacoes, e a utilizacao
ou integracao ao LDAP.
3.2.2.3 IBM Tivoli Directory Server
O Tivoli Directory Server foi desenvolvido pela IBM, baseado nas es-
pecificacoes do protocolo LDAP. Este tem como vantagem a utilizacao do IBM DB2, que
consiste em um sistema gerenciador de banco de dados. Com base nisto, o Tivoli Direc-
tory Server tem um armazenador de informacoes, o que e diferente para outros servicos
de diretorio, os quais procuram utilizar em suas implementacoes bases de dados menos
sofisticadas e especializadas em leitura. [TUTTLE, 2005] [ALVES, 2005]
Esta ferramenta disponibiliza suporte a varias ferramentas, tanto para
administracao do diretorio como para suporte a ferramentas via WEB. Alem disso, dis-
ponibiliza documentacao, para criacao de ferramentas clientes a fim de utiliza-la em seu
diretorio.
O Tivoli Directory Server pode ser utilizado em diferentes sistemas sis-
temas operacionais, como no MS-Windows 2000/2003 Server, Linux, AIX e no IBM
Z/Series. Este ainda pode ser considerado, depois do OpenLDAP, um servicos de di-
retorio com tecnologia aberta, ou seja, um dos servicos mais acessıvel do momento. Com
base nisto, este possui suporte a varios protocolos de seguranca, dentre eles o SASL e o
Kerberos.
39
3.2.2.4 Novell eDirectory
O eDirectory utiliza uma infra-estrutura baseada em padroes que per-
mite um controle facil e flexıvel diante as polıticas de seguranca da rede, aos admi-
nistradores. Servicos de criptografia e de autenticacao sao integrados com o diretorio,
possibilitando aos administradores um gerenciamento mais centralizado e controlado.
[Naguel, 2005] [ALVES, 2005]
Este e baseado na implementacao dos conceitos de LDAP e possui su-
porte a todas as especificacoes desse protocolo, sendo compatıvel com XML(Extensible
Markup Language), DSML(Directory Services Markup Language), SOAP(Simple Object
Access Protocol), entre outros. Alem disso, pode ser utilizado em plataformas GNU/Linux,
MS-Windows, SUN Solaris, IBM AIX, NOVEL NetWare e HP-UX. [EDirectory, 2005]
O eDirectory disponibiliza um controle real sobre a autenticacao e au-
torizacao dos usuarios, no sentido de que caso ocorra alguma interrupcao diante o contato
cliente/servidor, os recursos cedidos ao usuario sao imediatamente bloqueados. Alem
disso, ele possui suporte a cartoes inteligentes, tokens, certificados digitais, biometria e
alguns outros metodos de autenticacao.
3.2.2.5 AE Slapd
O AE Slapd e uma solucao de servidores LDAP, para plataformas como
GNU/Linux e MS-Windows. Este foi desenvolvido pela APS Engineering e tem como
base as funcionalidades da terceira versao do LDAP. [Naguel, 2005] [ALVES, 2005]
Diante as demais solucoes, pode-se dizer que este e menos complexo,
por utilizar um servico de acesso a diretorios simplificado. Porem este mostra-se eficiente
diante objetivos que nao requerem grande capacidade de armazenamento de informacoes.
Tambem possui suporte para administracao via web e para sistemas que necessitem de
diretorio e possuam o padrao LDAP como protocolo de comunicacao.
40
3.3 Modelos
Para uma boa utilizacao dos recursos disponibilizados pelo LDAP, deve-
se entender que e necessario realizar a modelagem das informacoes de um diretorio. Por
modelagem deve-se entender como o modo de sistematizar as informacoes de modo que
fiquem estruturadas e tenham o seu acesso otimizado. Para atingir tal estado e necessaria
a compreensao de todos os modelos (Informacao, Nomes, Funcionalidade e Seguranca)
que sao empregados na elaboracao dos diretorios e o funcionamento do protocolo de
comunicacao LDAP.
Tais modelos definem, respectivamente, as entradas de dados de um
diretorio, como estas sao organizadas e disponibilizadas, as funcoes para realizar o acesso,
a gerencia e as formas de autenticacao e autorizacao fornecidas pelo servico LDAP. Dentre
estes conceitos, varias sao as operacoes e as especificacoes envolvidas, todas com suas
funcoes e seus respectivos objetivos, buscando facilitar a comunicacao cliente/servidor.
3.3.1 Modelo de Informacao
O Modelo de Informacao (Information Model) define todas as entradas
de dados num diretorio. Tais entradas sao compostas de atributos, cada atributo tem um
tipo e um ou mais valores, conforme mostra a Figura 3.4. O tipo de atributo define os va-
lores que este pode ter, como numeros de telefone, nomes. Estes tipos sao estabelecidos
na definicao da sintaxe, que define qual tipo de valor pode ser armazenado no atributo.
[Voglmaier, 2004] [Vitorio, 2005] [Isquierdo, 2001]
Alem de definir quais informacoes podem ser armazenadas nos atribu-
tos, a sintaxe especifica como os valores devem se comportar durante as operacoes dentro
de um diretorio, como buscas, alteracoes, inclusoes ou exclusoes. Alguns exemplos de
sintaxe podem ser observados na Tabela 3.2.
Para exemplificar as funcionalidades geradas pela sintaxe, deve-se re-
lacionar os atributos a estas, gerando assim uma nova especificacao para os dados que
deseja-se atribuir ao diretorio. Na Tabela 3.3 tem-se como atributos o nome, sobrenome
e o telefone, suas respectivas sintaxes, descricoes e um exemplo.
41
Figura 3.4: Entradas e Atributos
Tabela 3.2: Exemplos de Sintaxe
Sintaxe Descricao
bin Informacao Binariaces Maiusculas e minusculas sao significantes na comparacao (case exact string)cis Maiusculas e minusculas nao sao significantes na comparacao (case ignore string)tel Numeros telefonicos. Numeros sao tratados como texto, sem considerar espacos em brancodn Diferenciar os objetos da arvore
Tabela 3.3: Exemplos de atributos relacionados as suas sintaxes
Atributos Sintaxe Descricao Exemplo
nome cis Primeiro nome Camilasobrenome cis Sobrenome da pessoa Tonezer
telefone tel Numero do telefone 445-0000
Estas informacoes sao organizadas em uma arvore de informacao de di-
retorio (DIT). O topo da DIT e a raiz do diretorio, este tambem e conhecido como diretorio
de entrada especıfica, nela sao listados os tipos de objetos que podem ser armazenados em
um diretorio e os atributos destes. [Vitorio, 2005] [Bernardes, 2005] [Isquierdo, 2001]
Estes atributos, referentes a uma determinada entrada, formam um grupo
que e chamado de Object Class. Alem disso, ao ser instanciada uma entrada pode-se
atribuır a esta uma ou mais classes de objetos. Estas classes possuem atributos opcionais
ou exigidos que fazem parte do diretorio. [Voglmaier, 2004] [Vitorio, 2005]
42
O diretorio LDAP e configurado para reconhecer varias classes de ob-
jeto, as quais definem a natureza das entradas no diretorio. Com base nestas especificacoes,
a implementacao do servidor de diretorio LDAP precisa de varias definicoes de classes de
objetos para especificar que tipo de entrada o diretorio pode ter. [Voglmaier, 2004]
Como o armazenamento do sistema e hierarquico, pode-se ter entradas
pertencentes a mais de uma classe de objeto. Estas entradas pertencem a classe especıfica
e tambem de onde esta classe foi derivada ou estendida. [Voglmaier, 2004]
Devido a estes conceitos, pode-se dizer que um objeto de LDAP e uma
representacao de um objeto do mundo real no diretorio, os quais usam um conjunto de
propriedades comuns e podem ser classificados. Esta classificacao e baseada em um con-
junto comum de atributos, os quais conduzem para uma hierarquia de objetos e dao origem
a classes de objeto que podem ser abstratas, estruturais ou auxiliares. [Voglmaier, 2004]
O nıvel superior desta hierarquia e construıdo por classes de tipo abs-
trata, sendo que este tipo de classificacao define um objeto que nao necessita ser imple-
mentado de fato. Um exemplo disto e a classe do topo, onde nenhuma entrada e imple-
mentada, mas e dela que todas as outras classes serao derivadas. [Voglmaier, 2004]
O tipo estrutural define os dados que serao armazenados no diretorio,
ou seja, estabelece a estrutura do diretorio. Estas informacoes que serao inseridas podem
ser dados de uma pessoa ou de organizacoes. Alem disso, algumas implementacoes de
servidor usam classes estruturais para definir onde as informacoes devem ser colocadas
na arvore de diretorio. [Voglmaier, 2004]
Ja a auxiliar e definida para situacoes que necessitam de uma nova
classe de objeto que estenda de uma outra ja existente. Este tipo nao ajusta a estru-
tura de objeto, para isto deve-se definir todas as informacoes que o novo objeto precisa
conter junto com uma classe auxiliar e este pode ser colocado em qualquer lugar da DIT.
[Voglmaier, 2004]
Estes tipos de classificacoes ajudam a realizar a configuracao e a estru-
turacao dos objetos e de suas classes dentro de um diretorio de dados, ou dentro da arvore
de informacoes de diretorios. Todos os dados inseridos na DIT devem ser especificados
de acordo com os tipos existentes e devem manter um padrao previamente estabelecido.
43
Baseando-se nisto, pode-se dizer que o Modelo de Informacoes e de
extrema importancia na definicao das entradas de dados e de seus respectivos atributos e
tipos. Alem disso, a especificacao da sintaxe e a definicao das classes de objetos auxiliam
na modelagem das informacoes dentro da DIT.
3.3.2 Modelo de Nome
O Modelo de Nome (Naming Model) descreve como as estruturas de
dados, entradas e classes de objeto, que usam elementos basicos, sao constituıdas, orga-
nizadas e identificadas. Este modelo define alguns conceitos sobre a DIT e a estrutura
de definicao dos nomes que especificam as entradas. [Voglmaier, 2004] [Vitorio, 2005]
[Isquierdo, 2001]
A DIT realiza a organizacao de seus dados, tornando mais facil fazer
a referenciacao destes, e define a estrutura das entradas do diretorio. Na Figura 3.5
pode-se observar um exemplo desta forma de organizacao, onde ”o”representa a universi-
dade , ”ou”determina os departamentos ou unidades organizacionais e ”uid”identifica os
usuarios para cada departamento. [Voglmaier, 2004] [Isquierdo, 2001]
Figura 3.5: Exemplo de uma Arvore de Informacoes de Diretorio
Estas entradas de dados tem atributos que sao baseadas em nomes dis-
tintos (DN), os quais dao sentido ao Modelo de Nomes. O DN e utilizado para realizar
44
a identificacao unica para cada entrada, ou seja, para tornar uma entrada unica entre as
demais existentes em um diretorio.
Os DN’s sao compostos de uma sequencia de relativos nomes distintos
(RDN - Relative Distinguished Name) e cada RDN corresponde a um ramo na DIT, desde
a raiz ate a entrada, a qual o DN faz referencia. Cada RDN e composto de atributos de sua
entrada no diretorio, o qual pode ser representado pela estrutura: <nome do atributo> =
<valor>, como cn = Camila Tonezer. [Voglmaier, 2004] [Isquierdo, 2001]
Ja um DN e formado por uma serie de RDN’s separados por vırgulas
como: cn = Camila Tonezer, o=pai, c=br. Neste exemplo, o DN e composto pelo RDN cn
= Camila Tonezer, que caracteriza um atributo de entrada, adicionado ao DN pai o=pai,
c=br. Com base nisto, uma serie de atributos e suas representacoes sao apresentados na
Tabela 3.4, os quais comumente sao indicados por strings que buscam facilitar o reconhe-
cimento [Voglmaier, 2004].
Tabela 3.4: Relacao dos principais atributos com suas respectivas representacoes
Tipo de Atributo String Definicao
CommonName cn Atributo que representa um nomeLocalityName l Atributo para expressar nome de localidades
StateOrProvinceName st Atributo para dar nome a provıncias ou estadosOrganizationName o Atributo que nomeia organizacoes
OrganizationalUnitName ou Atributo para nomear unidades organizacionaisCountryName c Atributo que representa nome de paısStreetAddress street Atributo que representa o endereco da rua
domainComponent dc Atributo para dar nome aos componentes de domıniouserid uid Atributo para indicar usuarios
Estes tipos de atributos combinados entre si e bem organizados, cons-
tituem os nos da DIT. Para a organizacao da arvore, uma sequencia relativamente com-
binada ao mundo real deve ser estabelecida e seguida pelas novas entradas que apare-
cerao, mantendo padrao. Alem desta distribuicao interna, uma DIT pode ter seus ramos
distribuıdos por mais de um computador, sendo possıvel encontrar um servidor LDAP
apenas com parte da arvore. Estas divisoes da DIT podem ser representadas por sufixos,
conforme Figura 3.6. Com isso, torna-se necessaria a existencia de uma ligacao entre
o servidor LDAP que armazena o ramo superior e aquele que armazena o ramo inferior
45
da arvore, sendo esta chamada de referencia. Diante desta forma de comunicacao entre
servidores e possıvel realizar a localizacao de informacoes. [Voglmaier, 2004]
Figura 3.6: Divisao de ramos
Na Figura 3.6, quando um cliente conecta-se ao servidor LDAP e soli-
cita uma informacao, o servidor processa este pedido e verifica que os dados solicitados
encontram-se em outro servidor. Diante disto, o servidor 1 envia uma resposta ao cliente
informando a referencia do local onde as informacoes estarao, conforme mostra a Figura
3.7. O cliente por sua vez, decide se seguira a indicacao e retoma ou nao a requisicao,
agora ao servidor indicado.
Figura 3.7: Servidor LDAP retornando referencia ao pedido
Alem disso, o servidor 1 pode realizar uma indicacao imediata, con-
46
forme a Figura 3.8, na qual a requisicao e feita pelo cliente e o servidor solicitado efetua a
comunicacao com o servidor onde os dados se encontram. Apos obter estas informacoes
o servidor 1 retorna-as ao cliente.
Figura 3.8: Servidor LDAP retornando resposta ao pedido
Para controlar as formas de realizar uma indicacao correta, surgiram
ferramentas que disponibilizam estas aplicacoes. Estas formas nao existem na segunda
versao do LDAP, elas somente apareceram na terceira versao, buscando padronizar as
entradas e suas respectivas sintaxes. [Voglmaier, 2004]
Sendo assim, o Modelo de Nome tem como objetivo organizar as en-
tradas dentro da arvore de informacoes de diretorio e definir como estas podem ser con-
figuradas e representadas atraves de uma sintaxe. Alem disto, este modelo define formas
de realizar a comunicacao de informacoes que estao em diferentes servidores, ou seja,
formas de comunicar partes separadas da DIT atraves de referencia. Estas referencias ser-
vem para informar o cliente de onde estao os dados solicitados ou, ate mesmo, responder
a solicitacoes cuja resposta se encontra em outro servidor LDAP.
3.3.3 Modelo Funcional
O Modelo Funcional descreve como as operacoes podem ser executadas
dentro do diretorio, ou seja, como o servidor trata as solicitacoes do usuario e como este
deve faze-las. Com base nisto, pode-se dizer que este modelo ainda especifica as funcoes
47
que o LDAP oferece para realizar o acesso e a gerencia das informacoes dentro de um
diretorio. [Voglmaier, 2004] [Vitorio, 2005] [Isquierdo, 2001]
Para que a comunicacao, cliente/servidor, possa ocorrer sao necessarios
determinados aspectos como classe de objeto, tipo de atributo, sintaxe, referencias e um
identificador de objeto unico (OID - Unique Object Identifier). Desta forma, o padrao do
LDAP descreve a natureza dos pedidos que o cliente pode enviar ao servidor, conforme
definido na RFC 2251. [Voglmaier, 2004]
Depois de receber o pedido, o servidor executa a operacao para somente
assim enviar uma resposta. Como as operacoes devem ser resolvidas e decidido pelo de-
senvolvedor ou pela organizacao que implementa o servidor de diretorio, porem estas sao
classificadas e definidas neste modelo, o qual objetiva o funcionamento da implantacao
do LDAP.
Para realizar a parte funcional da comunicacao existem tres tipos de
operacoes, sendo que todas consistem em pedidos feitos por um cliente de LDAP a um
servidor de LDAP [Voglmaier, 2004] [Quirino, 2005]:
1. Operacoes de interrogacao podem ser de dois tipos: de busca e de comparacao.
A de busca baseia-se na parte do diretorio onde as entradas que espelham-se em
uma condicao especıfica sao filtradas. Neste processo, e possıvel especificar como
a operacao deve acessar as informacoes do diretorio, o ponto da DIT onde o servi-
dor deveria comecar a busca, os atributos que envolvem a questao e um prazo para
o termino da busca no servidor. A comparacao realiza uma funcao semelhante a
operacao de busca, acessando o diretorio para achar algo referente a uma entrada.
Porem, este nao retorna nenhum dado somente mensagens informando se e verda-
deira ou falsa a comparacao.
2. Operacoes de atualizacao sao constituıdas de soma, exclusao, modificacao de DN e
simplesmente modificacao. A soma serve para adicionar uma entrada no diretorio,
o oposto da exclusao que serve para retirar uma determinada entrada da arvore. A
operacao de modificacao pode alterar ou ate mesmo apagar um ou mais atributos
de uma entrada. Ja a modificacao de DN, na terceira versao de LDAP, realiza a
48
alteracao dos dados incluindo a modificacao do DN, onde e removida a sua entrada
referente ao seu pai e inserida uma nova. Na segunda versao este processo era mais
simples e somente o DN relativo era alterado.
3. Operacao de autenticacao e formada por conexao e desconexao e a de controle por
abandono. A operacao de conexao permite que um usuario estabeleca conexao
com um servidor de diretorio LDAP. Esta e uma operacao de autenticacao pois o
usuario entra com um login e uma senha, os quais sao analisados pelo servidor. A
operacao de desconexao finaliza a conexao previamente estabelecida. Por sua vez,
a de abandono interrompe a conexao entre o cliente e servidor.
Estas operacoes detalham um nıvel muito abrangente de como e rea-
lizada a parte funcional do LDAP. Com o Modelo Funcional pode-se entender como e
realizada a gerencia das informacoes, entre ela alteracoes, buscas, exclusoes e adicoes,
e as formas de acesso ao diretorio, como autenticacao e controle. Buscando uma me-
lhor especificacao destas operacoes, torna-se importante um estudo mais detalhado das
informacoes e das funcionalidades referentes a estas.
3.3.3.1 Operacoes de Interrogacao
A operacao de busca (search) e realizada quando um usuario solicita ao
servidor de diretorios informacoes especıficas. Estes dados sao filtrados e enviados como
resposta ao cliente. Esta e a operacao mais complicada, pois pode ter muitos parametros,
como base, escopo, definicao de pseudonimos, limite de tamanho, limite de tempo, atri-
buto de retorno, filtro de busca, e lista de atributos. [Quirino, 2005]
A base define onde o processo deve comecar, ja o escopo especifica a
extensao da busca dentro da DIT. Na Figura 3.9, estao dispostos a base e o escopo da
busca, sendo que estes tem valores iguais, ou seja, um unico objeto (baseObject) repre-
senta o escopo.
Alem deste tipo, pode-se ter um escopo envolvendo um nıvel da arvore,
conforme a Figura 3.10. Neste a busca e feita nos objetos basicos e em seus filhos (sin-
gleLevel).
49
Figura 3.9: Busca com escopo igual a base
Figura 3.10: Busca com escopo igual a um nıvel da DIT
Outro exemplo pode-se obter na Figura 3.11, onde o escopo da busca
envolve uma parte da arvore, ou uma sub-arvore. Com isso, a busca estende-se a toda
sub-arvore do objeto basico.
50
Figura 3.11: Busca onde o escopo envolve uma parte da arvore
As definicoes de pseudonimos (derefAliases) indicam como estes de-
vem ser controlados, sendo usados como ligacoes simbolicas em um sistema de arquivo.
Em vez de conter uma entrada, este contem um objeto de uma classe de objetos particu-
lares que aponta a entrada que contem os dados reais. [Voglmaier, 2004] [Quirino, 2005]
O emprego deste tipo de parametro facilita ao servidor encontrar o que e desejado.
O tamanho limite (sizeLimit) e o limite de tempo (timeLimit) determi-
nam, respectivamente, o numero maximo de entradas e o tempo maximo em segundos
que deve levar a busca. Estes valores, se nao especificados pelo cliente serao definidos
como zero. [Voglmaier, 2004] [Quirino, 2005]
O atributo de retorno (attrOnly) trabalha com tipos booleanos, sendo
que se um valor indicar verdade serao retornados os tipos de atributos, porem se indicar
falso este retorna os tipos e os valores dos atributos. [Voglmaier, 2004] [Quirino, 2005]
Com isso, pode-se dizer que este parametro vem atribuir as respostas, fornecidas pelo
servidor ao usuario, dados que fazem parte da solicitacao feita.
51
Os filtros de busca (searchFilter) analisam as condicoes da solicitacao e
disponibilizam ao cliente os resultados referentes as condicoes de busca. Estas condicoes
podem ser combinadas com tipos booleanos utilizando os operadores ”e”, ”ou”, e ”nao”.
Para retornar os resultados estes filtros devem verificar se os dados sao identicos ou nao as
condicoes existentes, com isso e gerada uma lista de atributos (attributeList). Esta relacao
de informacoes sera retornada ao usuario, como resposta a sua busca. [Voglmaier, 2004]
[Quirino, 2005]
A operacao de comparacao (compare) serve para testar a presenca de
um atributo em uma entrada com um determinado DN. Esta apos realizar o teste retorna
verdadeiro caso na entrada for encontrado o atributo e falso se a entrada nao tiver o atri-
buto. Alem disso, ela contem parametros que sao entradas (entry) e afirmacao de valor do
atributo (ava). As entradas representam as informacoes ou DN que servem para realizar a
busca. Ja a ava define o nome e o valor do atributo que sera verificado. [Voglmaier, 2004]
[Quirino, 2005]
A operacao de interrogacao trabalha com a interacao direta entre o ser-
vidor e o diretorio, onde o cliente realiza uma solicitacao e o servidor de LDAP comunica-
se com o diretorio, percorrendo a arvore de informacoes, atras dos dados que irao satis-
fazer as necessidades do usuario. Para que isto ocorra e para facilitar este processo de
localizacao das informacoes, o usuario especifica uma serie de atributos.
3.3.3.2 Operacoes de Atualizacao
Uma operacao de atualizacao pode ser enquadrada sob tres formas [Quirino, 2005]:
1. Operacao de soma (add): realiza a insercao de informacoes dentro de um diretorio,
sendo de simples realizacao pois, contem somente dois parametros, a entrada (en-
try) e a lista de atributo (attributeList). A entrada e representada por um DN, a lista
de atributos por nome e valor de atributos da entrada.
2. Operacao de exclusao (delete): tem como funcao apagar os dados existentes na DIT.
Nela encontra-se um unico parametro, a entrada, que e utilizada para especificar o
DN a ser eliminado.
52
3. Operacao de modificacao (modify): tem o papel de realizar alteracoes e exclusoes
nos atributos das entradas. Sendo que esta, por sua vez, e definida por tres parame-
tros, o DN, o tipo da operacao e por combinacoes de nome e valor. Neste processo
a entrada ou DN representa a informacao que sera alterada. O tipo de operacao para
este contexto pode ser soma, exclusao ou ate mesmo modificacao.
O processo de modificacao de DN (modify DN) pode ser utilizado para
renomear uma entrada ou para mover uma entrada dentro de um diretorio. Os parametros
necessarios para modificar o DN de uma determinada entrada sao entrada, novo RDN
(newRDN), exclusao do antigo RDN (deleteOlRDN) e novo superior (newSuperior). Tendo
uma entrada a ser modificada e um novo RDN que sera inserido, a exclusao do velho RDN
ocorre e o novo e posicionado na arvore de acordo com o seu novo superior ou seu novo
pai. Na Figura 3.12, tem-se a representacao da operacao onde uma entrada e renomeada.
Neste exemplo somente o DN e renomeado e seu pai permanece o mesmo.
Figura 3.12: Modificacao de DN onde a hierarquia permanece a mesma
53
Alem disso, esta operacao possibilita que seja modificado o DN e tam-
bem sua hierarquia. Com isso, DN’s podem deslocar-se dentro da arvore, modificando
seu pai, conforme Figura 3.13.
Figura 3.13: Modificacao de DN com mudanca na hierarquia
A operacao de modificacao de DN possibilita ainda que a entrada seja
duplicada, ou seja, o local de origem permanece com o conteudo inicial e o local de
destino da modificacao tambem recebe este conteudo, Figura 3.14. Esta opcao e fornecida
ao usuario no momento da execucao.
54
Figura 3.14: Modificacao de DN mantendo o antigo
As operacoes de atualizacao realizam a modificacao dos dados dentro de
um diretorio. Levando em consideracao que estas permitem ao usuario realizar alteracoes,
adicoes e modificacoes das informacoes e pertinente que qualquer cliente LDAP que de-
seje realizar este tipo de processo, tenha um nıvel de acesso ou permissao definido na sua
identidade e que devem estar correlacionadas ao seu login.
3.3.3.3 Operacoes de Autenticacao e Controle
A operacao de conexao (bind) tem como objetivo conectar o cliente com
o servidor de diretorio LDAP. Esta tem como parametro a versao, o nome e a autenticacao.
Com isto, o usuario deve informar a versao de LDAP que deseja utilizar, o nome do objeto
55
de diretorio que este deseja conectar-se e a forma de autenticacao que pode ser simples
e SASL. A autenticacao simples onde o usuario informa o login e a senha para realizar a
conexao e a SASL que busca tornar segura nao somente o acesso como tambem o meio.
[Voglmaier, 2004] [Quirino, 2005]
A operacao de desconexao (unbind) e simples, pois nao tem nenhum
parametro. Alem disso, esta nao retorna valor ao usuario, sendo que este ao mandar
executar a operacao de desconexao ja assume que a mesma esta fechada. Com isso, o
servidor liberta qualquer recurso alocado para o usuario e fecha a conexao de TCP/IP.
[Voglmaier, 2004] [Quirino, 2005]
A operacao de controle abrange somente um tipo de operacao o aban-
dono (abandon), que serve para parar uma requisicao previamente solicitada. Esta tem
somente como parametro o ID operacao (operationID), que indica o ID da operacao que
deve ser terminada. Neste tipo de processo o servidor nao manda nenhuma resposta para
a operacao de abandono e o cliente nao recebe nenhuma resposta. [Voglmaier, 2004]
[Quirino, 2005]
Com base nestes conceitos, pode-se dizer que o Modelo Funcional per-
mite que determinadas operacoes sejam realizadas em um diretorio. Alem disso, e neste
modelo que sao definidas formas de como lidar com solicitacoes e respostas de, res-
pectivamente, clientes e servidores LDAP. Estas formas sao bem especificadas e suas
operacoes devem obedecer/informar determinados tipos de atributos e parametros. Di-
ante desta troca de informacoes existente entre cliente e servidor, alguns requisitos de
autorizacao e controle tambem sao especificados, buscando fornecer a seguranca ade-
quada os servicos de diretorios.
3.3.4 Modelo de Seguranca
Os modelos de Interrogacao, Nome e Funcional proporcionam muitos
elementos necessarios para construir um diretorio e a estrutura da arvore de diretorios.
Porem para que se possa projetar e manipular estes dados, com um nıvel de seguranca
aceitavel, e necessario a implementacao de mecanismos que garantam os aspectos basicos
56
de seguranca2.
O Modelo de Seguranca e importante porque o LDAP e um protocolo
orientado a conexao, o que o torna bastante acessıvel a qualquer usuario/aplicacao. Ao
iniciar uma comunicacao entre cliente e servidor, o servidor proporciona ao cliente deter-
minados tipos de credenciais, como por exemplo login e senha, para possa ser compro-
vada a sua identidade. Ao fazer isto, o servidor estabelece direitos de acesso para este
indivıduo, que estao atribuıdo ao seu login. Isso caracteriza dois argumentos que devem
ser protegidos: a autenticacao3 e a autorizacao4. [Voglmaier, 2004] [Isquierdo, 2001]
Na autenticacao o cliente identifica-se ao servidor tentando conectar-se.
Neste processo depende-se dos mecanismos de autenticacao empregados, onde pode-se
ter uma conexao anonima (para usuarios que desejam conectar-se sem obter uma identi-
dade) ou uma conexao utilizando autenticacao que pode ser simples ou com a utilizacao
de certificados digitais.[Voglmaier, 2004] [Martines, 2002] Ao estabelecer a conexao o
cliente e reconhecido pelo servidor e este concede determinados direitos de sobre os da-
dos contidos no diretorio.
Por autorizacao deve-se interpretar como a forma que o servidor con-
cede estes direitos de acesso ao cliente anteriormente autenticado. Os direitos concedidos
pelo servidor representam o que o usuario pode ler e o que ele pode escrever dentro de
um diretorio. Para definir o que cada cliente pode fazer, o servidor necessita manter um
arquivo com determinadas informacoes de controle de acesso (ACI - Access Control In-
formation). [Voglmaier, 2004] [Martines, 2002]
O Modelo de Seguranca busca garantir a seguranca das informacoes do
diretorio, porem, este ainda esta sendo aperfeicoado, principalmente no que tange ao as-
pecto de autorizacao. A segunda versao de LDAP iniciou o processo da implementacao
de autorizacao, sendo que na terceira versao ja existem diversas especificacoes, entre-
tanto nao tantas necessarias para um perfeito funcionamento. Para maior detalhamento
destes aspectos de seguranca e necessario um estudo mais especıfico sobre autenticacao e
2Confidencialidade, integridade, disponibilidade e autenticidade.3Autenticacao e o processo de identificacao positiva dos clientes.4Autorizacao controla quais os recursos e as operacoes o cliente tera permissao de acesso.
57
autorizacao.
3.3.4.1 Autenticacao
Buscando realizar o processo de autenticacao foi desenvolvida a RFC
2829 - Authentication Methods for LDAP. Nela estao definidos varios ıtens exigidos pelo
LDAP, dentre os quais destacam-se:[Voglmaier, 2004] [Martines, 2002]
• Autenticacao de Cliente: O cliente realiza a autenticacao, informando seu login e
sua senha ao servidor de diretorios. Para este processo o cliente utiliza certificados.
• Autorizacao de Cliente: O servidor controla, por mecanismos de controle de acesso,
o que o cliente pode solicitar ao diretorio. Estes direitos sao baseados na sua
autenticacao.
• Mecanismo de Integridade de dados: Garante que as informacoes enviadas pelo
usuario chegue ao servidor e as enviadas pelo servidor ao usuario.
• Protecao contra Intrusao: Impede que pessoas nao autorizadas tenham acesso a
comunicacao entre cliente e servidor.
• Protecao contra Monopolizacao: Recursos de limites estabelecidos para evitar que
um usuario monopolize o sistema, afetando a disponibilidade do mesmo.
• Autenticacao do Servidor: O servidor realiza sua autenticacao, comprometendo-se
a responder as requisicoes do cliente.
Diante destes aspectos, e definicoes, o LDAP busca garantir a auten-
ticacao tanto dos usuarios como do servidor. Este processo envolve toda a seguranca
dos dados do diretorio e das solicitacoes/respostas enviadas entre a comunicacao cli-
ente/servidor.
A autenticacao existente nas especificacoes de LDAP podem ser de di-
ferentes nıveis, envolvendo varios metodos para que um cliente possa realizar a autenti-
cacao. Este metodos podem ser [Carter, 2003]:
58
• Acesso Anonimo: Esta forma de acesso tambem pode ser chamada de conexao
anonima, pelo fato do servidor nao saber quem esta solicitando uma conexao. A co-
nexao anonima e utilizada para realizar o acesso de informacoes publicas, como por
exemplo uma lista de telefones publicos. O servidor e quem determina se o acesso
anonimo sera disponibilizado e qual o nıvel de acesso que os usuarios anonimos
devem ter. Alem disso, o servidor pode assumir uma conexao anonima se o cliente
nao tiver acesso autorizado ou previamente estabelecido.
• Autenticacao Simples: Esta forma de autenticacao e simples e e utilizada em outros
protocolos como o HTTP. O cliente envia suas credenciais, login ou DN e senha,
ao tentar se conectar ao servidor. Este envio e realizado sem a utilizacao de crip-
tografia e isso e uma forma nao adequada aos requisitos de seguranca (no aspecto
de confidencialidade). O servidor, ao receber a identificacao do usuario, realiza
uma busca para identificar se o DN e autorizado. Se este for encontrado a conexao
e estabelecida, senao o servidor encaminha uma mensagem de erro ao cliente e a
conexao nao e estabelecida.
• Autenticacao Simples com a utilizacao de criptografia: Para realizar a cifragem das
informacoes o LDAP utiliza o SSL, o qual implementa mecanismos de seguranca
no protocolo TCP/IP. O SSL e baseado em criptografia de chave publica e foi desen-
volvido pelo Netscape Communications. Outro protocolo utilizado na especificacao
do LDAP e o TLS, o qual originou-se da terceira versao do SSL. A integracao deste
no LDAP foi estabelecida na terceira versao. Seu objetivo e prover integridade e
privacidade de dados, ou seja, o TLS garante que o envio de informacoes entre cli-
ente/servidor seja assegurado e que uma pessoa nao possa interceptar a conversacao,
conforme pode e mostrado na Figura 3.15.
O TLS inclui dois protocolos diferentes, o TLS Record e o TLS Handshake. A
funcao do protocolo TLS Record e somente encapsular o protocolo mais alto, o
protocolo TLS Handshake prove de mecanismos de seguranca, permitindo ao cli-
ente/ servidor autenticar e cifrar os dados utilizando chaves de criptografia.
59
Figura 3.15: Protecao ao meio de transmissao das informacoes
• Autenticacao com criptografia e certificados: Para garantir a seguranca das informacoes
que trafegam entre cliente/servidor e prevenir contra acessos nao autorizados, a se-
gunda versao do LDAP adotou mecanismos de conexao baseados em Kerberos.
Este consiste em um mecanismo de seguranca planejado para ser utilizado em am-
bientes que necessitam de seguranca na Internet, serve para realizar a autenticacao
diante do cliente e esta definido na RFC 1510 - The Kerberos Network Authenti-
cation Service (v5). Com o Kerberos, a comunicacao e codificada e a identidade
assegurada ao ponto de garantir que o cliente e quem diz ser ao tentar realizar a
conexao. Para isso, o servidor disponibiliza ao cliente uma chave da sessao cifrada,
a fim de que este possa realizar a conexao autenticando-se. O protocolo Kerberos e
estavel, realiza muitas das exigencias de seguranca, podendo ser usado por muitos
protocolos e interpretado por plataformas independentes. Porem, ate a versao atual,
o uso deste nao garante total seguranca. Para isso, foram agregados protocolos de
seguranca como o SASL, o qual fornece de servicos de autenticacao a protocolos
orientados a conexao (TCP). O padrao de SASL esta definido na RFC 2222 - Simple
Authentication and Security Layer, e utiliza mecanismos similares ao do Kerberos.
A autenticacao fornece ao servidor as credenciais, do cliente, necessarias
para que a conexao possa ser estabelecida e permite que ambos possam verificar a iden-
tidade alheia. Apos realizada a conexao, servidor e cliente podem trocar mensagens sem
que as informacoes sejam modificadas por um outro usuario nao autorizado. Para que esta
questao de autenticacao possa ser prevenida tornou-se necessario que mecanismos e pro-
tocolos de seguranca (Kerberos, SASL, TLS e SSL) fossem adicionados as especificacoes
60
do LDAP de modo a criar uma infra-estrutura de seguranca adequada aos diferentes con-
textos em que esta inserido.
3.3.4.2 Autorizacao
A autorizacao ou o controle de acesso e o processo pelo qual um ser-
vidor concede direitos de acesso a um cliente anteriormente autenticado. Os servicos de
diretorios buscam implementar solucoes para este fim, porem elas tambem podem ser en-
contradas em softwares especıficos, os quais tem sua propria solucao. [Voglmaier, 2004]
Autorizacoes estabelecem as permissoes de acesso que um usuario pode
exercer diante a utilizacao das informacoes em um diretorio. Estas permissoes vao limitar
as acoes e operacoes que um cliente tem direito. Alem disso, estas sao estabelecidas no
momento em que o usuario tenta uma conexao ao servidor. [MOTTA, 2001]
A partir do momento que o cliente executa uma operacao de conexao
(bind), este fornece a sua identificacao (DN), credenciais de autenticacao, senha, cha-
ves privadas, entre outros. Diante destas informacoes, uma lista de controle de acesso
(ACL) e consultada a fim de determinar que entradas do diretorio o cliente pode ver e que
alteracoes ele tem permissao para fazer. [MOTTA, 2001]
A fim de garantir o processo de autorizacao, o servidor de LDAP man-
tem uma lista (ACL) contendo as informacoes de controle de acesso (ACI). Porem, toda
implementacao de servidor tem sua propria maneira de trabalhar com a ACI. Pode-se citar
como exemplo o OpenLDAP, que mantem estas informacoes nos arquivos de configuracao,
e o Netscape que as mantem no diretorio. [Voglmaier, 2004] Diante disto, pode-se dizer
que o controle de acesso das informacoes podem conter as seguintes especificacoes:
• Protecao de dados: Pode-se restringir o acesso de um determinado usuario a uma
parte da DIT, a um DN ou liberar para que este possa acessar toda a arvore.
• Acesso de dados: Pode-se definir quais clientes terao acesso ao sistema.
• Nıvel de acesso: Pode-se definir direitos de acesso ao usuario.
61
• Restricao de requerimentos: Pode-se restringir o numero de IP ou o nome do host
a ser encontrado.
Com base nestes conceitos, pode-se dizer que a autorizacao vem pro-
porcionar ao cliente LDAP determinados direitos de acesso, com base em sua identidade
digital. Tais acessos definem ate onde o usuario pode utilizar (modificar, adicionar ou
excluir) os dados existentes em um diretorio e quais informacoes este podera ter acesso.
3.4 Modelagem de Identidades
A identificacao de pessoas podem ser realizada de diferentes formas,
como pela cedula identidade, CPF, pela carteira de motorista, por passaporte, cartoes
magneticos de funcionarios ou por cartoes de clubes. Estas maneiras de identificacao po-
dem conter informacoes exclusivas do ser proprietario, como nome, sobrenome, endereco,
foto e dados das autoridades que emitiram o documento. [Morgan, 2005]
Com base nisto, pode-se dizer que a nocao de identidade no mundo
fısico e mais compreendida do que as definicoes para modelagem de identidades digitais.
A modelagem de identidades digitais e formada de partes como um identificador, suas
credenciais, principais atributos e os atributos especıficos do contexto, conforme a Figura
3.16 [Chong, 2004] [Morgan, 2005]:
Figura 3.16: Analise da Identidade Digital. Adaptado de [Chong, 2004]
62
• O identificador e a informacao que identifica o objeto dessa identidade, com ex-
clusividade , dentro de um determinado contexto. Pode-se citar como exemplo de
identificadores os enderecos de e-mail e os nomes distintos.
• As credenciais sao informacoes privadas ou publicas que podem ser usadas para
provar a autenticidade de qualquer solicitacao de identidade. Um exemplo para ex-
plicar esta parte de uma identidade pode ser encontrado quando um usuario informa
sua senha, ao servidor, a fim de estabelecer conexao. Neste momento somente o sis-
tema de autenticacao e o cliente devem saber qual a senha informada. Diante disto,
pode-se dizer que uma chave privada e o certificado de chave publica associados
sao exemplos de credenciais.
• Os principais atributos sao dados que auxiliam a descricao da identidade e estes po-
dem ser utilizados em diversos contextos comerciais e de aplicacoes. Tem-se como
exemplo os numeros de telefones e enderecos, onde ambos podem ser utilizados e
consultados por diferentes aplicacoes.
• Ja os atributos especıficos de contexto sao informacoes que tambem ajudam a des-
crever a identidade, porem sao utilizadas e consultadas somente dentro do contexto
especıfico no qual a identidade e utilizada. Pode-se citar como exemplo, em uma
empresa, os dados do plano de saude do funcionario sao atributos especıficos de
um contexto, pois estes interessam a assistencia medica e nao ao setor de servicos
financeiros.
Diante de tantas informacoes e da necessidade de protecao destas, torna-
se necessario que ocorra um gerenciamento das identidades digitais. Este gerenciamento
consiste em um conjunto de processos de negocio e uma infra-instrutura com suporte para
a criacao, manutencao e uso destas identidades, ou seja, o gerenciamento de identidade
refere-se ao processo, as tecnologias e as polıticas para gerenciar as identidades digitais e
controlar o uso destas para acessar recursos.
Com isso, pode-se estabelecer uma estrutura que represente a geren-
ciamento e o acesso de identidades, como mostra a Figura 3.17. Esta estrutura tem tres
63
partes fundamentais, o gerenciamento do ciclo de vida da identidade, o gerenciamento de
acesso e os servicos de diretorios. No ciclo de vida de uma identidade sao gerenciados
os usuarios, as credenciais, as habilidades e a integracao de identidades. Para o acesso
sao gerenciados a autenticacao, a confianca e federacao, as habilidades e autorizacao, a
auditoria de seguranca, a propagacao de identidade, a personificacao e a delegacao. Ja os
servicos de diretorio oferecem determinada infra-estrutura para atender o armazenamento,
o gerenciamento e as buscas dos dados de forma segura. [Chong, 2004]
Figura 3.17: Exemplo de alguns componentes logicos. Adaptado de [Chong, 2004]
Para garantir a seguranca das informacoes, processos de autenticacao,
autorizacao e auditoria5 sao disponibilizados em servicos de diretorio e incluem a gerencia
de acessos, para evitar intrusao. Estes conceitos abrangem todo o ciclo de vida de uma
identidade, (estagios como: criacao, utilizacao e termino). Durante a criacao de uma
identidade digital, as informacoes precisam ser propagadas e inicializadas nos sistemas
de identidade, alem disso, estas ainda podem ser amplificadas, ou seja, dados podem ser
adicionados dependendo da necessidade existente. Depois de que a identidade nao estiver
em atividade esta deve ser excluıda ou seu status alterado. [Chong, 2004]
Existem varios nıveis para que a realizacao do gerenciamento do ciclo
5Auditoria e o processo realizado para contabilizar e registrar eventos de seguranca.
64
de vida de uma identidade seja realizado. Na Figura 3.18, estao representados os nıveis
existentes que podem ser representados pelos seguintes dados [Chong, 2004]:
Figura 3.18: Nıveis do ciclo de vida de uma identidade
• Nıvel de Dados da Identidade: As credenciais representam senhas e certificados,
as habilidades sao direitos e privilegios e os atributos podem ser nome, endereco e
numero de telefone.
• Nıvel de Operacoes de Dados: Representa as operacoes que podem ser realizadas
com os dados da identidade, como criar, ler, atualizar e excluir.
• Nıvel de Modelos de Administracao: Podem ser classificados como auto-servico,
onde os usuarios atualizam alguns de seus dados, e administracao delegada, onde
as responsabilidades da administracao do ciclo de vida da identidade sao comparti-
lhadas entre grupos de administradores.
• Nıvel de Situacao de Negocio: Representa a modificacao das identidades no sentido
de alterar um usuario de grupo, excluir este ou adicionar.
Com a apresentacao de como funciona o ciclo de vida pode-se rela-
tar necessidade existente de um usuario ter uma unica identidade para acessar diferentes
servicos. Como mostra a Figura 3.19, sem a integracao dos dados um usuario tem que
65
lidar com varias identidades digitais, as quais sao armazenadas e gerenciadas de forma
independente.
Figura 3.19: Exemplo da utilizacao de varias identidades para diferentes sistemas. Adaptado de[Chong, 2004]
Com base nisto, problemas podem ser constatados, como a duplicacao
de informacoes e a falta de integracao destas. Estes problemas fazem com que o usuario
seja cadastrado em diferentes sistemas e consequentemente seus dados sejam duplicados.
[Carvalho, 2005b]
Alem disto, um outro problema consiste na necessidade do usuario de
informar varios logins e senhas em diferentes sistemas que este necessite acessar. Do
ponto de vista do usuario, este procedimento exige que sejam memorizados e relacio-
nados os sistemas e suas respectivas formas de acesso. Ja do lado do gerenciamento,
incidentes como o esquecimento de senhas aumentam o custo de gerenciamento e quando
combinados com habitos incorretos de gerenciar senhas de usuarios, podem levar a um
aumento de vulnerabilidades de seguranca. [Carvalho, 2005b]
Tentando solucionar esses tipos de problemas e facilitar o gerencia-
mento de identidades e de acesso uma solucao chamada Single Sign-On (SSO), foi es-
tudada, desenvolvida e aprimorada. Dentre esta solucao tem-se cinco classes, que repre-
sentam diferentes situacoes de aplicacoes [Chong, 2004] [Carvalho, 2005b]:
• SSO na Web: Usuarios de navegadores nao autenticados sao redirecionados a sites
de login para introduzir as identificacoes e credenciais de usuarios. Depois de ser
66
realizada a autenticacao, cookies HTTP sao emitidos e utilizados pelas aplicacoes
Web a fim de validar as sessoes autenticadas.
• Sign-On Integrado no Sistema Operacional (SO): Refere-se a modulos de autenti-
cacao e interfaces desenvolvidas no SO.
• Sign-On Federado: Necessita que as infra-estruturas de autenticacao de aplicacoes
compreendam as relacoes de confianca e interoperabilidade atraves de protoco-
los padroes. Isto significa que a responsabilidade de autenticacao e repassada a
alguem de confianca. Neste caso, um usuario nao precisa realizar o processo de
autenticacao novamente.
• Mapeamento de Identidade e Credencial: Sao caches de credenciais para manter
o controle das identidades e credenciais que podem ser utilizadas para acessar as
listas correspondentes de sites de aplicacoes.
• Sincronizacao de Senha: E utilizada para sincronizar senhas em bancos de dados de
credenciais de aplicacoes de forma que o usuario e o sistema nao precisem gerenciar
varias alteracoes em senhas. Esta classe pode fazer com que uma aplicacao de
camada intermediaria trate uma senha como a mesma para varios sistemas.
Diante disto, torna-se necessario realizar o gerenciamento das habilida-
des, o qual refere-se ao conjunto de tecnologias usado para conceder e invocar direitos
de acesso e privilegios para a modelagem de identidades. Com base na utilidade e na ne-
cessidade de utilizacao de esquemas de autenticacao, nem sempre fica esclarecido como
deve ser modelada uma estrutura de gerenciamento de habilidades.
Para tal, deve-se analisar todos os direitos pertencentes a uma determi-
nada identidade. Diante disto e para satisfazer e facilitar o gerenciamento, as organizacoes
aproveitam para realizar o armazenamento de diretivas de forma centralizada.
As mudancas ocorridas diariamente fazem com que ocorra a necessi-
dade de reorganizar a modelagem das identidades, incluindo seus direitos de acesso. Em
muitas vezes, uma duplicacao de dados do usuario ocorre, gerando redundancias e assim
67
dificultando o gerenciamento das informacoes. Para agregar estas identidades, deve-se
trabalhar com a manutencao de relacoes para que se possa transformar os dados, com a
otimizacao de operacoes de dados e com a sincronizacao de destes. [Carvalho, 2005b]
Na Figura 3.20, pode-se observar o processo onde a construcao de um
unico diretorio e realizada e a modelagem das identidades digitais dos usuarios e atualiza-
da a cada mudanca. Neste exemplo, ocorre uma conciliacao de registros e as identidades
serao utilizadas pelos usuarios para realizar o acesso de diferentes sistemas.
Figura 3.20: Exemplo da integracao de identidades de varios sistemas em uma unica identidadedigital
Isso proporciona varios benefıcios para as aplicacoes, como o forneci-
mento de aplicacoes com uma visao unica ou agregada dos dados de sistemas individuais,
conforme a Figura 3.21. Nesta, dois diferentes esquemas de modelagem de identidades
sao unidos e transformados em uma so modelagem.
Para o acesso aos dados de uma identidade e necessaria a existencia de
questoes de confianca, as quais podem implicar em delegacao de responsabilidades, ou
68
Figura 3.21: Exemplo da integracao de dados de varios sistemas em uma unica identidade digital
seja, na criacao de federacoes. A federacao e um repasse de responsabilidades honra-
das por meio de relacoes de confianca entre as partes federadas. Sao exemplos desta o
MEC, o Lattes, o DataCapes, o IBICT, o ensino a distancia, as bibliotecas, entre outros.
[Carvalho, 2005a]
As federacoes nao buscam criar uma identidade unica, mas sim traba-
lhar como uma corporacao distribuindo as tarefas entre as partes, onde as identidades sao
armazenadas localmente e acessadas por mecanismos especiais. Esta forma de tratamento
de dados apresenta vantagens como seguranca, diminuicao de custo e ainda facilidades
administrativas, como flexibilidade para autenticar os usuarios de organizacoes. [?]
Muitas formas de funcoes podem ser delegadas a alguem de confianca,
como a autenticacao, a autorizacao, o gerenciamento de perfis, os servicos de pseudonimo
e a cobranca. Para que isso possa ser executado tres elementos fundamentais devem ser
69
respeitados [Chong, 2004]:
• Um protocolo de comunicacao: Este tem como funcao realizar a comunicacao entre
as partes federadas.
• Uma infra-estrutura: Esta deve ser de confianca, flexıvel e que ofereca suporte a
uma variedade de modelos de confianca.
• Uma estrutura de gerenciamento: Onde sao gerenciadas diretivas extensıveis que
oferece suporte a distintos requisitos de controle.
Para realizar a comunicacao entre as partes federadas sao utilizados pro-
tocolos de federacao. Estes devem disponibilizar recursos para que as partes federadas
possam executar suas tarefas com eficacia. [Chong, 2004]
Com base nestes conceitos, pode-se dizer que a necessidade de gerar
uma identidade unica para cada usuario poder acessar varios sistemas tem crescido com o
aumento de sistemas dentro de uma organizacao e com a constante modificacao de aces-
sos disponibilizados aos usuarios. Esta centralizacao das informacoes, correspondentes a
cada usuario, vem diminuir a replicacao e a redundancia dentro de um diretorio. Alem
disso, a modelagem de identidades para os usuarios proporciona uma consideravel me-
lhora a utilizacao e ao gerenciamento dos dados de um diretorio.
3.5 Conclusao
Neste capıtulo foram relatados os principais conceitos envolvendo o
LDAP, desde sua definicao, funcionamento, versoes, aplicacoes e modelos, bem como
deve ser a criacao e a modelagem de identidades digitais para um diretorio. Tais aspectos
sao considerados essenciais para entender como este protocolo vincula-se aos servicos de
diretorio.
Os modelos de Informacao, Nome, Estrutural e de Seguranca do LDAP
relatam a comunicacao com o diretorio, como sao definidos os atributos, seus tipos e
70
valores, como as estruturas de dados, entradas e classes de objeto sao constituıdas, or-
ganizadas e identificadas, como sao descritas as operacoes que realizam a comunicacao
cliente/servidor, e como deve ser a seguranca dos dados e do processo de comunicacao.
Diante disto, pode-se relatar a importancia que contem estes modelos, pelo fato de que
eles auxiliam a organizacao, a especificacao e o manuseio das informacoes de um di-
retorio.
Com isto previamente definido, foram apresentados dados sobre a criacao
e a importancia de identidades. Estas foram desenvolvidas para que as informacoes de
sistemas independentes fossem incorporadas em um unico diretorio, evitando assim a
duplicacao e a inconsistencia dos dados.
Capıtulo 4
OpenLDAP
Para poder gerenciar e utilizar as informacoes contidas em um diretorio
e necessario que haja uma implementacao das definicoes oferecidas pelo LDAP. Com
isso, pode-se dispor das funcionalidades do protocolo, a fim de resolver problemas de
informacoes de uma rede de computadores.
Diante desta necessidade, a implementacao do OpenLDAP mostra-se
funcional e suas aplicacoes e operacoes abrangem aspectos necessarios para tal. Suas ca-
racterısticas e sua disponibilidade vem destaca-lo diante das outras ferramentas de acesso
e gerencia de informacoes de um diretorios. Entre estas pode-se relatar [Voglmaier, 2004]:
• O OpenLDAP e um software de codigo aberto, com licenca publica e seu codigo
fonte pode ser encontrado de adquirido gratuitamente;
• Possui versoes que sao compatıveis e foram adaptadas a terceira versao do LDAP;
• Trabalha em diferentes plataformas, como GNU/Linux, Solaris, MS-Windows;
• Desenvolvido pela Universidade de Michigan para ser compatıvel ao LDAP e, com
isso, realizar a conexao e a comunicacao entre cliente/servidor.
Conforme especificado nas definicoes do LDAP, o OpenLDAP vem rea-
lizar a comunicacao entre o cliente e o servidor. Devido a suas caracterısticas e definicoes,
pode-se dizer que o OpenLDAP disponibiliza muitos recursos e aplicacoes para realizar
72
o acesso e a gerencia das informacoes de um diretorio. Dentre estas, estao os daemons1
slapd e slurpd, os quais realizando suas respectivas funcoes dao maior funcionalidade aos
quizitos pre-definidos pelo OpenLDAP.
4.1 Slapd e Slurpd
A comunicacao entre o cliente e o servidor e feita com base em API’s
e utilizando servicos destinados a realizar a configuracao. Tais arquivos, disponibiliza-
dos pelo OpenLDAP, sao chamados de ldap.conf e slapd.conf. O arquivo de ldap.conf
configura parametros para aplicacoes de cliente, e isso e especificado de distintas formas
dependendo de como o usuario realiza a configuracao. Ja o arquivo slapd.conf e onde
estao as informacoes para a configuracao do servidor OpenLDAP (slapd), do daemon de
replicacao (slurpd). [Carter, 2003]
Alem disso, o arquivo slapd.conf pode ser utilizado para gerenciar os
parametros que afetam o comportamento global dos servidores de OpenLDAP, ou de
parametros que sao relacionados a um banco de dados usados pelo daemon de slapd.
A configuracao do slapd e armazenada como um diretorio especial de LDAP, para isso
ele deve conter um esquema e uma arvore predefinidos. Estes podem ser representados
conforme a Figura 4.1, onde sao especificados comandos globais, definicoes de schemas,
de backend e de banco de dados [Foundation, 2005].
Figura 4.1: Elementos usados para configuracao do slapd
1Daemons sao sistemas residentes, ou seja, nao sao configurados de forma a utilizar informacoes
contınuas do usuario. Assim este desconecta-se do terminal na primeira oportunidade. [Anonimo, 2005a]
73
A arvore da configuracao de slapd.d e bem especıfica, onde na raiz
encontram-se os ajustes globais da configuracao e nos outros nos tem-se os ajustes adi-
cionais que representam as entradas. Com base nisso, pode-se dizer que as entradas sao
especificadas de acordo com tais definicoes, as quais tem como base os conceitos que
envolvem o LDAP. [Foundation, 2005]
O OpenLDAP, alem de conter pacotes que trabalham com configuracao,
aplicacao e manutencao de servicos de cliente e servidor, especifica bibliotecas de desen-
volvimento. Estas podem ser apresentadas em conjunto a varios componentes conforme
a Tabela 4.1.
Tabela 4.1: Componentes do OpenLDAP
Nome Descricao
libexec/slapd Servidor LDAPlibexec/slurpd Auxiliar de Replicacao
bin/ldapadd, bin/ldapmodify, bin/ldapdelete e bin/ldapmodrdn Tratar entradas de dados no diretoriobin/ldapsearch e bin/ldapcompare Realizar operacoes de buscas e comparacoes
bin/ldappasswd Tratar atributos de senhassbin/slapadd, sbin/slapcat e sbin/slapindex Manipular dados usados em slapd
sbin/slappasswd Utilizar e simplificar o uso de senhas no slapd.conf
O funcionamento proporcionado pelo slapd pode ser estendido para su-
portar sintaxes adicionais, tipos do atributo e classes do objeto. Estas ampliacoes podem
ser feita de cinco formas:
• Obtendo um identificador de objetos: Cada elemento do schema e representado por
um identificador global original do objeto (OID), sendo que estes sao usados para
identificar outros objetos. Sao usados pelo Simple Network Management Protocol
(SNMP). Por ser organizado em forma hierarquica, estes podem ser representados,
conforme a Figura 4.2 [Foundation, 2005]:
• Escolhendo um prefixo especıfico: Deve-se fornecer pelo menos um nome para
cada elemento e estes devem ser descritivos. Estes devem ser diferentes dos nomes
padroes previamente estabelecidos e padronizados;
• Criando um arquivo local de schema: As classes de objetos e as diretrizes da
configuracao dos tipos de atributos podem ser usados para definir as entradas no
74
diretorio. Para isso, tais devem ser armazenados e organizados em um arquivo lo-
cal;
• Definindo tipos de atributos: A diretriz orientadora do tipo de atributo e utilizada a
fim de definir um novo tipo de atributo. Esta usa a mesma descricao definida pela
RFC 22522;
• Definindo classes de objetos: A diretriz orientadora das classes de objeto e usada
para definir uma classe nova do objeto. Esta usa a mesma descricao definida na
RFC 2252.
Figura 4.2: Elementos que constituem a DIT para OpenLDAP
Com a utilizacao e a configuracao do slapd e do slurpd, pode-se alme-
jar a comunicacao entre cliente/servidor. Atraves destes, parametros e definicoes sao
previamente estabelecidos a fim de tornar abrangente e compatıvel a forma de trocar
informacoes.
4.1.1 Replicacao com slurpd
A troca de informacao cilente/servidor pode ser feita atraves de uma
unica instancia do slapd. Porem isso pode ser insuficiente para responder a quantidade2A RFC 2252 (Lightweight Directory Access Protocol (V3): Definicoes de sintaxe de atributos.) repre-
senta os valores dos atributos para realizar a transmissao no protocolo LDAP, definindo os valores inteiros,
selo de hora, enderecos de email e outros.
75
de clientes que necessitam de servicos de diretorio LDAP. Para satisfazer tais necessida-
des, utilizando a replicacao, pode-se configurar o DNS de tal forma que seja retornado o
endereco IP de um desses servidores de cada vez, distribuindo a carga entre eles (mestres)
ou entre os escravos. A forma com que e feita a replicacao pode ser observada na Figura
4.3.
Figura 4.3: Replicacao de dados
Com isso, a comunicacao torna-se simples e efetiva, aumentando a ca-
pacidade, a disponibilidade e a confiabilidade do servico. O slurpd realiza este servico de
replicacao utilizando o mesmo canal que os clientes utilizam para acessar os servidores
escravos, ou seja, atraves do protocolo LDAP. Pode-se ter como exemplo a Figura 4.4 e
4.5.
76
Figura 4.4: Comunicacao entre o Slapd Mestre e o Escravo
Conforme a Figura 4.4, o cliente LDAP envia uma operacao de modifi-
cacao ao slapd escravo. Este retorna uma referencia para o cliente, redirecioando-o para o
slapd mestre. Ja o cliente LDAP, por sua vez, envia o pedido de modificacao para o slapd
mestre, o qual realiza a operacao, escreve a mudanca no log de replicacao e retorna um
codigo de sucesso para o cliente.
Figura 4.5: Processo Slurpd
Na Figura 4.5, o processo slurpd descobre que uma nova entrada foi
colocada no final no arquivo do log de replicacao, entao este realiza a leitura da entrada
do log de replicacao e envia a mudanca para o escravo via LDAP. Este realiza a operacao
e retorna um codigo de sucesso para o processo slurpd.
77
Ao ser configurado, o slapd gerar um arquivo de log de replicacao, este
contem registros de modificacoes no formato LDIF e informa o local da(s) replica(s), o
DN da entrada que sera modificada e as linhas que especificam as mudancas a serem
realizadas.
4.1.2 Autenticacao e Autorizacao
A fim de garantir a seguranca diante o acesso as informacoes de um
diretorio, o OpenLDAP disponibiliza recursos para tratar a autenticacao e a autorizacao.
Tais recursos sao correspondentes e especificados com os mesmos parametros e as mes-
mas definicoes da terceira versao do LDAP.
Os diretorios foram desenvolvidos para dar resposta rapida a um grande
volume de consultas e operacoes de busca. Estes tambem podem replicar informacoes, e
isto e usado para acrescentar disponibilidade, confiabilidade e reduzir o tempo de resposta.
As diferentes formas de disponibilizar um servico de diretorio, vem per-
mitir que distintos tipos de informacoes possam ser armazenadas, referenciadas, requisi-
tadas, atualizadas e protegidas de acessos nao autorizados. A protecao contra acessos nao
autorizado nao e comum para todos os servicos de diretorios, sendo que isso permite que
qualquer pessoa possa ver os dados existentes.
Com base no modelo de seguranca do LDAP, OpenLDAP vem dis-
por de diversas funcionalidades para assegurar a identificacao, a autenticacao de um cli-
ente, provando sua identidade diante do diretorio, e o controle de acesso, protegendo as
informacoes contidas no servidor. Como na especificacao do LDAP, isso e feito atraves
da operacao bind.
Depois que o usuario e autenticado e identificado, um controle de acesso
e disponibilizado a fim de determinar se o usuario tem permissao para fazer o que ele
solicitou. Alem disso, o usuario pode nao se identificar, ou seja, acessar o diretorio como
anonimo, assim sendo este tambem vai receber certos controle de acesso aos dados de um
diretorio.
78
4.2 Conclusao
Neste capıtulo foram relatados os principais conceitos envolvendo o
OpenLDAP, como seu funcionamento, principais caracterısticas e funcionalidades. Tais
aspectos buscam representar os fatores que implicaram na escolha desta ferramenta para
implementar o modelo proposto.
Alem disso, e apresentado como o OpenLDAP pode-se realizar a co-
municacao entre cliente/servidor atraves dos daemons, slapd e slurpd, disponibilizados
por este. Estas funcionalidades buscam caracterizar as formas com que esta ferramenta
trabalha e os servicos que ela pode disponibilizar.
Com isto previamente definido, foram relatados as formas de autenticacao
e autorizacao do OpenLDAP. Estes conceitos espelham-se nos apresentados anterior-
mente com a terceira versao do LDAP e buscam, respectivamente, validar o login e a
senha de um usuario e disponibilizar permissoes de acesso.
Capıtulo 5
Analise e Modelagem das Identidades
dos Sistemas da UDESC
Com base na necessidade de integracao dos dados de diferentes sistemas
em um unico diretorio e na criacao de uma unica identidade para cada usuario, deve-se
analisar as informacoes contidas nas bases de dados e a forma com que estas sao acessa-
das, ou seja, a forma com que a autenticacao e a identificacao sao realizadas. Diante disto,
varios dados e informacoes foram coletados, envolvendo diferentes sistemas da UDESC.
Tais sistemas tem distintas funcionalidades e buscam, de forma geral,
auxiliar e armazenar as informacoes necessarias e utilizadas diariamente, a fim de dispor
seus dados a pesquisas e atualizacoes constantes. Porem todos estes sistemas tem suas
bases de dados individuais o que causa duplicidade e redundancia de informacoes entre
eles.
5.1 Sistemas e Servicos Existentes
Para a utilizacao, no Centro de Ciencias Tecnologicas da UDESC (Join-
ville), estao dispostos diversos sistemas e servicos como o SigmaWeb, o Pergamum, o
Sistema de Empenho, o Sistema de Viagens, a Intranet, o Sistema de Bolsas de Apoio
Discente e a disponibilizacao de contas de usuarios, de servicos de correio eletronico, de
80
ADSL e de acesso via VPN. Cada qual possui seus respectivos objetivos e informacoes
as quais sao armazenadas isoladamente, fazendo com que nao exista integracao entre os
sistemas.
5.1.1 SigmaWeb
O SigmaWeb e o aplicativo de registro e controle academico utilizado
pela UDESC, o qual visa possibilitar o controle dos alunos, alunos visitantes e profes-
sores. Dentre estes, varias funcionalidades estao co-relacionadas, como a matrıcula dos
alunos e professores e a possibilidade de acesso as informacoes dos cursos, disciplinas,
professores, currıculos, notas, presencas, historicos escolares, requerimentos, entre ou-
tros, como mostra o Apendice D. [UDESC, 2005]
Este sistema foi desenvolvido em PHP e utiliza o banco de dados MySQL.
Sua base de dados localiza-se no centro de Lages, base unica para todos os centros da
UDESC, onde sao disponibilizadas informacoes pra consulta, atualizacoes e cadastros. A
forma de autenticacao referente a este e constituıda de dois campos, matrıcula e senha,
conforme Figura 5.1. A matrıcula e uma informacao unica para cada usuario, ou seja,
para cada novo cadastro.
Figura 5.1: Tela de autenticacao do SigmaWeb
81
A partir deste ponto os dados sao relacionados com diversas outras in-
formacoes, que vao caracterizar e constituir o cadastro. Excluindo-se os atributos do
usuario, todos os outros dados sao informacoes especıficas do Sistema Academico, as
quais determinam suas funcionalidades e seus objetivos.
5.1.2 Pergamum
O Pergamum (Sistema Integrado de Bibliotecas) e um sistema informa-
tizado de gerenciamento de Bibliotecas, este foi desenvolvido pela Divisao de Processa-
mento de Dados da Pontifıcia Universidade Catolica do Parana. O Sistema foi imple-
mentado para comunicacao com base na arquitetura cliente/servidor, utilizando banco de
dados relacional. [PUCPR, 2005]
Este contempla as principais funcoes de uma biblioteca, com a funcio-
nalidade de integrar desde a aquisicao de materiais ate o emprestimo destes, tornando-se
assim um software de gestao de Bibliotecas. Desde o inıcio de sua comercializacao em
1997, este esta sendo utilizado em 101 instituicoes. [PUCPR, 2005]
Seu objetivo e utilizar conceitos e ideias de cada instituicao a fim de
mante-lo atualizado e atuante no mercado, tornando-o capaz de gerenciar qualquer tipo
de documento. Alem disso, o Pergamum atende Universidades, Faculdades, Centros de
Ensino de primeiro e segundo grau, assim como empresas, orgaos publicos e governa-
mentais. [PUCPR, 2005]
Este sistema contempla cadastros, como o cadastro de usuarios, que
podem ser professor, aluno, tecnico administrativo da UDESC ou aluno visitante, e o
cadastro de emprestimo (livros, jornais, entre outros). O cadastro de usuarios, busca
conter os dados necessarios para uma possıvel identificacao deste, conforme a Figura 5.2
e seus dados complementares dispostos no Apendice E.
82
Figura 5.2: Tela de Cadastro de Usuario do Pergamum
A partir do momento que estas informacoes sao cadastradas, o empres-
timo de livros pode ser realizado e a identificacao do usuario feita. Alem disso, pode-
se observar que no Sistema Pergamum utilizado na UDESC, abrange duas formas de
identicacao para o usuario, uma que e realizada com uma matrıcula gerada pelo sistema
e outra que utiliza a mesma matrıcula disponibilizada pelo SigmaWeb, padrao este que
vem sendo imposto nos ultimos anos.
5.1.3 Sistema de Empenho
O Sistema de Empenho da UDESC consiste em realizar o empenho de
compras de materiais e/ou prestacao de servicos. Este e solicitado atraves da ficha de pre-
empenho, conforme Apendice F, sendo que e nela que estao as informacoes necessarias
83
para realizar a solicitacao do servico.
Apos serem adicionadas ao Sistema de Empenho, como mostra o Apendice
G, tais informacoes sao analisadas por funcionarios do setor financeiro do CCT, bem
como o Diretor Geral, os quais tem acesso ao sistema. Desta forma, os dados sao valida-
dos a fim de estabelecer uma pertinencia ao pagamento.
Este sistema foi desenvolvido na linguagem PHP e utiliza o banco de
dados MySQL. Sua base e unica e esta localizada geograficamente em Florianopolis.
5.1.4 Sistema de Viagens
O Sistema de Viagens visa possibilitar a solicitacao de diarias e trans-
portes (recursos financeiros) para viagens com fins especıficos ou objetivos em prol da
Universidade. Tal solicitacao e realizada atraves deste sistema que esta disponıvel no site
da UDESC (Joinville).
Ao realizar a solicitacao de recursos o usuario estara preenchendo in-
formacoes condizentes a viagem, conforme Apendice H. Tais dados serao analisados por
funcionarios da Secretaria Geral e/ou pelo Diretor Geral do CCT.
Este sistema foi desenvolvido em PHP e utiliza o banco de dados MySQL.
Sua base de dados esta localizada no campus de Joinville e e utilizada so por este. A forma
de autenticacao deste sistema e feita pelos seis primeiros dıgitos da matrıcula do Sistema
Academico, como mostra a Figura 5.3. Alem disso, nao existe nenhuma validacao refe-
rente a isto, ou seja, qualquer valor pode ser informado no campo matrıcula que o sistema
nao verifica a existencia.
84
Figura 5.3: Tela de Autenticacao do Sistema de Viagens
5.1.5 Intranet
A Intranet disponibiliza varios servicos como agenda, lista de usuarios,
disponibilidades de horarios, de contatos, de classificados, de notıcias e de telefones.
Alem disso, pode-se realizar a reserva de recursos, como som, canhao, TV, vıdeo, sa-
las, auditorio e anfiteatro, bem como a solicitacao de servicos prestados pelo suporte da
Universidade. Tais servicos podem ser observados nas telas dispostas no Apendice I.
O acesso a este sistema e restrito aos professores, funcionarios e bol-
sistas. Com suas respectivas permissoes e nıveis de agrupamento1, estes usuarios tem
1Sao nıveis de permissoes dadas aos usuarios a fim de diferenciar qual grupo este encaixa-se.
85
diferentes servicos disponibilizados.
A Intranet foi desenvolvido na linguagem Java, utiliza o banco de da-
dos MySQL e o TomCat disponibilizando servicos de solicitacoes ao servidor. Sua base
localiza-se e e propria do Centro de Joinville. A autenticacao e realizada atraves de um
login e uma senha, como mostra a Figura 5.4. Diante disto, pode-se dizer que este pro-
cesso e particular e, por consequencia, causador de redundancias e falta de integracao das
informacoes existentes entre os sistemas.
Figura 5.4: Tela de Autenticacao da Intranet
5.1.6 Sistema de Bolsas de Apoio Discente
O Sistema de Bolsas de Apoio Discente tem como objetivo realizar os
processos de cadastro, alteracao de cadastro e consulta da situacao da bolsa de traba-
86
lho disponibilizada pela UDESC. [UDESC, 2005] Com ele cada aluno pode realizar sua
inscricao a fim de participar da selecao de candidatos para as bolsas2.
Os dados de cadastro do usuario sao apresentados no Apendice J e bus-
cam contemplar as informacoes necessarias para este sistema. Estes sao dispostos em
partes como identificacao, preferencia de atuacao, situacao socio-economica e disponibi-
lidade para trabalhar.
A Sistema de Bolsas foi desenvolvido em PHP e utiliza o banco de
dados MySQL. Sua base localiza-se em Joinville e e utilizada por outros centros. A
autenticacao deste sistema e feita pela matrıcula e pela senha do usuario, conforme a
Figura 5.5, porem estas informacoes sao cadastradas pelo proprio usuario e nao validadas
de acordo com os dados existentes nos cadastros da Universidade. Diante disto, pode-se
ter informacoes nao consistentes e redundancia dos dados, pelo fato de um usuario poder
cadastrar seus dados mais de uma vez.
Figura 5.5: Tela de Autenticacao do Sistema de Bolsas de Apoio Discente
2As descricoes desse processo de selecao sao feitas com base na Resolucao presente no site da UDESC.
87
5.1.7 Conta de Acesso ao Domınio
Para ter acesso as contas de usuarios disponibilizadas pela UDESC
basta preencher uma ficha de inscricao, conforme Apendice K. Nesta estao as informacoes
necessarias para que a liberacao da conta seja realizada.
A liberacao e feita manualmente pelos funcionarios do Suporte do CCT
e com isso, um login e uma senha sao disponibilizados para a autenticacao. O login e
criado a partir de informacoes pre-definidas que descrevem o tipo de usuario e o depar-
tamento ou atuacao que ele pertence, conforme as Tabelas 5.1 e 5.2. Com a uniao destas
informacoes, sao formadas composicoes como mostra a Tabela 5.3.
Tabela 5.1: Siglas que diferenciam a atuacao
Sigla do Departamento Descricao da Sigla
dcb Departamento de Ciencias Basicas e Sociaisdcc Departamento de Ciencias da Computacaodec Departamento de Emgenharia Civildee Departamento de Emgenharia Eletricadem Departamento de Emgenharia Mecanicadep Departamento de Emgenharia de Producaodfi Departamento de Fısica
dma Departamento de Matematicaesp Contas Especiaisfej Funcionarios
Tabela 5.2: Tipos de usuario
Tipo de Usuario Descricao do Usuario
2 Professor6 Aluno7 Funcionario
Tabela 5.3: Exemplos de contas
Exemplos de Nomes Composicao Final da Conta
Camila Tonezer (ct) dfi6ctJuliana Patrıcia Detroz (jpd) dcc6fbe
Joao Pereira (jp) dee2jpBruna Benvenutti Eccel (bbe) dma2bbe
88
Como mostram as Tabelas, existe uma sequencia que representa res-
pectivamente a sigla do departamento, a classificacao do usuario e as iniciais do nome do
portador da conta. Alem disso, para os tipos de usuario sao determinados tamanhos dife-
rentes de contas, assim alunos tem um espaco disponıvel de 4 MB, o que e diferenciado
dos professores e funcionarios, os quais tem 10 MB para armazenamento.
5.1.8 Correio Eletronico
A disponibilidade do correio eletronico oferecida pela UDESC e soli-
citada atraves do preenchimento das informacoes contidas no Apendice K. Com estes
dados os funcionarios do Suporte podem liberar o acesso e uma conta de e-mail. A fim
de criar uma autenticacao para o solicitante, formas foram definidas e sao seguidas, como
mostra a Tabela 5.1 e a 5.2. Diante disso, pode-se ter como exemplo os enderecos da
Tabela 5.4.
Tabela 5.4: Exemplos de e-mail
Nome Endereco de Correio Eletronico
Camila Benvenutti Eccel (cbe) [email protected] Silho (js) [email protected]
A disponibilidade de tamanho para o correio eletronico e especificada
conforme as contas de usuarios, ou seja, para alunos 4 MB e para professores e fun-
cionarios 10 MB. Alem disso, e diponibilizada a funcionalidade de utilizar o e-mail como
alias3.
5.1.9 Servico de ADSL
A UDESC ainda oferece um servico de autenticacao para ADSL, no
qual a partir de uma conta de correio eletronico pode-se obter um login e uma senha para
utilizar o provedor da Universidade. Este cadastro e feito conforme mostra o Apendice L.
3Alias e enderecos de e-mail que nao tem um espaco definido nem senha e seu objetivo e direcionar as
mensagens para uma conta POP existente em outra conta.
89
5.1.10 Servico de VPN
Disponibiliza um servico de Virtual Private Network (VPN) para servicos
e sistemas internos especıficos (como o acesso de portal do CAPES), oferecidos pela
UDESC. Para utiliza-lo e necessario que um cadastro seja preenchido, Apendice K, neste
sao informados os dados necessarios para a identificacao do usuario.
5.2 Estrutura do Diretorio
A analise dos sistemas existentes na UDESC, foi realizada a partir de
entrevistas e coleta de informacoes, a fim de dispor de um consideravel conteudo para
que a modelagem pudesse ser desenvolvida. As entrevistas foram feitas com pessoas
responsaveis pela manutencao e/ou com usuarios dos mesmos, estes por sua vez, dispo-
nibilizaram todo material possıvel e existente para a construcao deste.
Diante da analise feita, diversos resultados foram obtidos e, consequen-
temente, uma representacao para um diretorio foi especificada. Conforme a Figura 5.6,
tem-se a forma mais adequada para organizar as informacoes da estrutura proposta. No
no raiz encontra-se a UDESC e em suas ramificacoes estao dispostos o CCT, o Centro
de Ciencias Agroveterinarias (CAV), o Centro Educacional do Oeste (CEO), o Centro de
Ciencias da Educacao (CCE-FAED), o Centro de Educacao a Distancia (CEAD), o Cen-
tro de Artes (CEART), o Centro de Educacao Fısica, Fisioterapia e Desportos (CEFID) e
a Escola Superior de Administracao e Gerencia (ESAG). Esta divisao foi feita por refle-
tir a estrutura organizacional da UDESC e pode ser analisada diante sua implementacao
conforme Apendice M.
90
Figura 5.6: Representacao da Arvore de Diretorios
A partir disto, o centro de Joinville (CCT) foi expandido nos quatro
tipos de usuario identificados, os quais sao alunos, professores, funcionarios e adminis-
tradores. Isto foi especificado porque os sistemas analisados tem seus acessos restringidos
de acordo com esta classificacao. No quarto nıvel da DIT, estao os objetos que represen-
tam os usuarios propriamente ditos. Tais objetos sao instancias da classe Usuario, a qual
esta detalhada nos diagramas de classes das Figuras 5.7 e 5.8.
91
Figura 5.7: Modelo que representa os nıveis de acesso
92
Figura 5.8: Modelo de diretorios e seus respectivos dados
93
Buscado atender ao objetivo de propor um modelo que realize a integra-
cao das autenticacoes dos diversos sistemas da Universidade4, foi elaborado o diagrama
da Figura 5.7. Este tem como principal objetivo contemplar os atributos necessarios, a
fim de nivelar as permissoes de acesso de acordo com as classes:
• Centro: os objetos desta classe representam os centros da Universidade, como o
CCT, o CAV, CEO, CCE-FAED, CEAD, CEART, CEFID e a ESAG;
• Usuario: e uma classe abstrata que contem os atributos comuns a todos os tipos de
usuarios. Entre eles destacam-se a matrıcula, que e um identificador unico para os
sistemas, o login, o qual tambem e unico, com a diferenca que este e um identi-
ficador que sera usado para realizar os acessos aos sistemas, e a senha que e uma
credencial que garante a autenticidade. Alem disso, tem-se o campo contaAtiva que
informa a ativacao de uma conta para o usuario e o auxiliar DeAutenticacao, o qual
foi projetado para possıveis autenticacoes/identificacoes atraves do uso de cartoes
ou outros auxiliares para tal;
• TipoAluno: os objetos desta classe representam os tipos de aluno, que podem ser
alunos regularmente matriculados ou alunos visitantes;
• Aluno: e uma subclasse concreta de Usuario, a qual nao tem atributos especıficos,
porem sua existencia facilita a expansao do sistema, a fim de diferenciar estes dos
outros tipos de acesso/usuarios;
• TipoBolsista: os objetos desta classe representam os tipos de bolsista, que podem
ser de pesquisa, de extensao ou e trabalho;
• Bolsista: esta classe herda as caracterısticas de Aluno, incluindo uma associacao do
tipo agregacao com a classe TipoBolsista. Devido a este relacionamento, a classe
Bolsista contem um atributo implıcito que possibilitara o acesso a determinados
sistemas de acordo com o tipo do bolsista;
4Como parte inicial, sendo que o diretorio pode ter sua estrutura expandida para incorporar novos siste-
mas/finalidades.
94
• Departamento: os objetos desta classe representam os departamentos da Universi-
dade, como Departamento de Ciencias da Computacao (DCC), Departamento de
Engenharia Eletrica (DEE), Departamento de Engenharia Mecanica (DEM), entre
outros;
• TipoProfessor: os objetos desta classe representam os tipos de professor, que podem
ser de Coordenador de Curso, Chefe de Departamento, Diretor Geral, entre outros;
• Professor: e uma subclasse de Usuario com um relacionamento do tipo agregacao
com a classe Departamento. Com isso, pode-se filtrar acesso de acordo com esta
informacao;
• Setor: os objetos desta classe representam os setores da Universidade, entre eles o
Financeiro, o Administrativo, o de Compras, entre outros;
• Funcionario: e uma subclasse de Usuario com um relacionamento do tipo agregacao
com a classe Setor. Desta forma, filtra-se o acesso baseado nestas informacoes;
• FuncionarioVisitante: esta classe representa os funcionarios de outras instituicoes
que prestam servicos a Universidade;
• Administrador: e uma subclasse de Usuario que contem atributos especıficos e
representa pessoas responsaveis pela administracao dos sistemas, bem como do
proprio diretorio.
Na Figura 5.8, estao representados os atributos que sao comuns entre os
sistemas existentes na UDESC e os que podem ser pontos de extensao de novos sistemas.
Dessa forma pretende-se evitar redundancia de dados, bem como inconsistencias entre
os diversos sistemas no que tange os dados referentes aos usuarios. Com base nisto, as
expansoes do primeiro modelo para o segundo sao:
• A classe Pessoa que contem os atributos comuns aos quatro tipos de usuarios, que
nao sao utilizadas para controle de acesso, sendo esses o telefone, o email, o celular,
o sexo, a identidade, o Orgao Emissor e o CPF;
95
• As classes Aluno, Funcionario, Professor e Administrador, que no primeiro modelo
herdavam as caracterısticas de Usuario, agora passaram a ser sub-classes de Pessoa,
que por sua vez e filha de Usuario;
• A classe Endereco especifica dados de localizacao que sao utilizados em varios
sistemas, estes sao: logradouro, numero, complemento, bairro, CEP, cidade, UF e
pais;
• A inclusao do tıtulo do professor, que representa a graduacao deste, a fim de titular
e diferenciar Especialistas, Mestres, Doutores, entre outros;
• A classe RegimeDeContratacao que distingue, como por exemplo, professores co-
laboradores de efetivos;
• O curso no qual o aluno esta matriculado e representado pela classe Curso, sendo
que esta informacao e de vital importancia para os diversos sistemas que fazem
parte da UDESC.
Com base nesses dados, pode-se dizer que este modelo busca englobar
os atributos que fazem parte da estrutura do diretorio proposto, a fim de satisfazer a ne-
cessidade de integracao das informacoes, eliminando as redundancias e as inconsistencias
entre varios sistemas existentes. Alem disso, este tambem foi desenvolvido visando con-
templar possıveis novas aplicacoes de forma que estas ja tenham uma modelagem pre-
definida.
5.3 Conclusao
Neste capıtulo foram apresentados os principais sistemas e servicos uti-
lizados no CCT/UDESC, como o SigmaWeb, o Pergamum, o Sistema de Empenho, o Sis-
tema de Viagens, a Intranet, o Sistema de Bolsas de Apoio Discente e a disponibilizacao
de contas de usuarios, de servicos de correio eletronico, de ADSL e de acesso via VPN.
96
Para cada sistema foram descritas informacoes que contemplam suas
principais caracterısticas, funcionalidades e funcionamento. Alem disso, foram levanta-
das as formas de autenticacao/identificacao existentes e os cadastros realizados.
Estas informacoes foram analisadas dando origem a um modelo que
trata as formas e nıveis de acesso e os dados mais relevantes e redundantes destes sistemas/
servicos. Com base nisto, uma modelagem padrao e generalizada foi relatada, buscando
sempre nao intervir nas funcionalidades proprias ou individuais de cada sistema.
Capıtulo 6
Consideracoes Finais
O LDAP e uma simplificacao do DAP, porem com muitas de suas fun-
cionalidades. Diante disto, pode-se dizer que este e de facil compreensao e fora elaborado
de modo a disponibilizar sua implantacao em diferentes plataformas e em ambientes com
poucos recursos computacionais e integrar os dados existentes em diferentes sistemas.
Esta integracao e baseada na criacao de identidades digitais, as quais facilitam a gerencia
de dados de um diretorio e os processos de autenticacao e autorizacao, diante cliente e
servidor.
Buscando realizar uma modelagem das informacoes, definindo identi-
dades para os usuarios, deve-se saber tambem como funciona a comunicacao entre um cli-
ente e um servidor, a fim de verificar como e realizada a comunicacao com os dados dentro
do diretorio, como sao definidos os atributos, seus tipos e valores, como as estruturas de
dados, entradas e classes de objeto sao constituıdas, organizadas e identificadas, como
sao descritas as operacoes, as quais definem formas de comunicacao cliente/servidor, e
como devem ser tratados os dados para que se obtenha seguranca. Tais definicoes relatam,
respectivamente, os Modelos de Informacao, Nome, Estrutural e de Seguranca.
Com base nas diversas especificacoes, necessarias para definir um di-
retorio, e na necessidade de modelar as identidades deste, pode-se dizer que existe o
problema de como definir tais identidades. Tal fato e proveniente da dificuldade de en-
contrar literaturas a respeito (sobre modelagem e definicoes de identidades) e pela falta
98
de um padrao a ser seguido, ou seja, por esta tender a ser implıcita e empırica.
Este tipo de modelagem, e determinacao de como sao especificadas
as identidades, podem ser encontradas em trabalhos desenvolvidos pela UFRGS e pela
UFRJ. Porem, cada um deles adotou sua propria forma de desenvolvimento e aplicabi-
lidade. Nesses dois casos os requisitos sao analisados e com base nestes o trabalho e
executado, nao aparentando empregar uma metodologia especıfica, ou seja, aparentando
ser executado de modo empırico.
O modelo proposto neste trabalho teve como base uma pesquisa reali-
zada (levantamento de dados) com os usuarios dos sistemas e servicos do CTT/UDESC.
Tais informacoes foram analisadas de forma geral, a fim de eliminar as redundancias
existentes. Alem disso, esta modelagem leva em consideracao as informacoes necessarias
para unificar os dados relativos a identificacao/autenticacao. Essa abordagem, de modelar
a identificacao do usuario, foi seguida em funcao da necessidade em encontrar um ponto
de convergencia de todos os sistemas que pudesse ser empregado como base comum a
modelagem dos sistemas existentes e futuros.
Outra consideracao relevante pode ser feita quanto aos aspectos tec-
nologicos disponıveis para implementacao do LDAP. Comprovou-se que existem solucoes
disponıveis para varias plataformas de sistemas operacionais para implementacao do ser-
vidor nao sendo este fator um impecilho a implementacao do servico. Porem analisando
do lado cliente percebe-se que cabe ao desenvolvedor de aplicativos implementar o pro-
cesso de gerenciamento do LDAP (consultas, insercoes, exclusoes, etc) no seu software,
empregando os padroes de comunicacao que sao abertos e de domınio publico. Obser-
vando esses pontos chegou-se a conclusao que o LDAP nao e mais empregado devido
a ausencia de capacitacao (e em determinadas situacoes o desconhecimento que existe o
proprio recurso)por grande parte dos desenvolvedores de aplicativos, que acabam gerando
redundancias e inconsistencias recriando recursos que ja existem.
No decorrer da realizacao deste, a maior dificuldade foi a de identi-
ficar as informacoes que sao comuns nos sistemas e servicos, pois estes nem sempre
tinham documentacao. Com base nisso, conclui-se que alguns sistemas podem conter
informacoes em comum que nao foram identificadas e consequentemente analisadas.
99
Baseando-se na modelagem sugerida, trabalhos futuros podem ser fei-
tos relacionados a este, como a sua implantacao e a forma de integracao/utilizacao deste
para outros centros. Isso mostra-se estimulante ao fato de que, uma vez realizadas es-
tas adaptacoes, varios sistemas e centros poderao ter acesso a uma forma de padro-
nizar/centralizar as informacoes e gerenciar estas com maior facilidade, possibilitando
tambem ao usuario um unico meio de acesso e maior seguranca.
Com a execucao deste trabalho foram atingidos os objetivos definidos
no projeto de acordo com o planejado. Observando o Apendice B, constata-se que todo
o cronograma foi seguido, com alguns atrasos devido a falta de materiais, porem mesmo
assim os objetivos puderam ser conquistados. Estes objetivos podem ser representados
pela contextualizacao apresentada neste trabalho, gerando assim uma contribuicao para
o entendimento dos conceitos e definicoes, que proporcionaram a base teorica para a
realizacao do modelo proposto. Alem desses fatos, varios outros assuntos interessantes
de pesquisar foram revelados, sendo que os mesmos nao foram abordados por nao estarem
inseridos nos objetivos/escopo desse estudo.
Diante do escopo pre-definido, pode-se concluir que a necessidade da
criacao e desenvolvimento dos servicos de diretorios surgiu devido a grande quantidade
de sistemas isolados, os quais geravam replicacao de dados e consequentemente incon-
sistencia destes. Com o objetivo de sintetizar e unir estas informacoes, eliminando as
redundancias, foram especificados padroes, protocolos, modelos, servicos e aplicacoes
que tem como base as funcionalidades do protocolo LDAP.
Referencias Bibliograficas
[Allen, 2003] Allen, R. (2003). Active Directory Cookbook. O’Reilly.
[ALVES, 2005] ALVES, J. M. (2005). Proposta de Uso Do Protocolo LDAP Na Infra-
Estrutura Da UDESC-Joinville.
[Anonimo, 2005a] Anonimo (2005a). Daemons, sinais e controle de processos. Dis-
ponıvel em: <http://www.openit.com.br/freebsd-hb/basics-daemons.html>.
[Anonimo, 2005b] Anonimo (2005b). Fatos e numeros: O uso da mnemonica. Dis-
ponıvel em: <http://www2.uol.com.br/publifolha/lv 262a.htm>.
[Archives, 2005] Archives, I. F. (2005). Internet RFC STD/FYI/BCP archives. Dis-
ponıvel em: <http://www.faqs.org/faqs/ >.
[Bernardes, 2005] Bernardes, M. C. (2005). Senha universal com LDAP. Disponıvel em:
<http://www.usp.br/cci/downloads/SenhaUniversal LDAP.ppt#19>.
[Brito, 2005] Brito, I. C. (2005). Servico de Ddiretorio. Universidade Catolica do Salva-
dor.
[Carneiro, 2005] Carneiro, L. F. (2005). Rotea-
dores e seguranca em redes. Disponıvel em:
<http://www.apostilando.com/download final.php?cod=342&autenticado=nao>.
[Carter, 2003] Carter, G. (2003). LDAP System Administration. O′Reilly.
[Carvalho, 2005a] Carvalho, Osvaldo; Buzato, L. E. (2005a). GT-middleware. Dis-
ponıvel em: <http://www.rnp.br/ arquivo/documentos/pal0221.pdf>.
101
[Carvalho, 2005b] Carvalho, Osvaldo; Buzato, L. E. (2005b). Middlleware universitario:
Vantagens da adotacao por universidades. Disponıvel em: <http://www.dirigentes-
tiifes.ufrgs.br/6encontro/Palestra%2018 GT%20Middleware%20MECRNP-
ANDIFES.pps>.
[Carvalho, 2005c] Carvalho, Osvaldo; Rodriguez, N. J. E. P. D. (2005c). GT - diretorios:
Uma arquitetura de autenticacao e autorizacao para a universidade brasileira. Dis-
ponıvel em: <http://www.rnp.br/ arquivo/gt/2003/diretorios.pdf>.
[Chong, 2004] Chong, F. (2004). Gerenciamento de identidade e acesso. JOURNAL3
Jornal de Arquitetos da Microsoft, pages 20–31.
[Craft, 2001] Craft, Melissa C.; Llewellyn, T. (2001). Windows 2000 Active Directory, 2
Ed. Syngress Publishing.
[EDirectory, 2005] EDirectory, N. (2005). Novell. Disponıvel em:
<http://www.novell.com/ptbr/products/edirectory/>.
[Filho, 2005] Filho, A. R. (2005.). X.500: Um servico de diretorio para
redes de computadores em ambientes heterogeneos. Disponıvel em:
<http://www.pr.gov.br/batebyte/edicoes/1995/bb45/x500.htm>.
[Foundation, 2005] Foundation, O. (2005). Configuring slapd. Disponıvel em:
<www.openldap.org>.
[Garcia, 2005] Garcia, L. F. F. (2005.). X.500. Disponıvel em:
<http://penta2.ufrgs.br/rc952/trab2/x500.html>.
[Goldani, 2005] Goldani, C. A. (2005). Seguranca em redes de telecomunicacoes. Dis-
ponıvel em: <http://www.unicert.com.br/files/doc/unicert08.doc>.
[GSI, 2005] GSI, G. d. S. d. I. (2005.). Servico de di-
rectoria para a universidade do minho. Disponıvel em:
<http://campusvirtual.uminho.pt/uploads/Servico Directoria.pdf>.
102
[Guimaraes, 2005] Guimaraes, J. d. O. (2005.). Apostilas de padroes de projeto e fra-
mework. Disponıvel em: <http://www.dc.ufscar.br/ jose/courses/oc/pct.htm>.
[Hoffman, 2004] Hoffman, Marc; Hoffman, L. A. P. (2004). Active Directory By the
Numbers: Windows Server 2003. Numbers Publications.
[House, 2000] House, Daniel E.; Hahn, T. M. L. D. R. (2000). E-Directories: Enterprise
Software, Solutions, and Services. Pearson Education Corporate Sales Division.
[Isquierdo, 2001] Isquierdo, G. S. (2001). Integracao do servico de diretorio LDAP com
o servico de nomes CORBA.
[Kanies, 2001] Kanies, L. A. (2001.). An introduction to LDAP. Disponıvel em:
<http://www.onlamp.com/pub/a/onlamp/2001/08/16/ldap.html>.
[Kellermann, 2005] Kellermann, Gustavo Adolfo; Silvello, J. C. (2005).
Programacao distribuıda e paralela: OpenLDAP. Disponıvel em:
<http://planeta.terra.com.br/informatica/silvello/openldap/ >.
[Komarinski, 2005] Komarinski, M. (2005.). LDAP − lightweight di-
rectory access protocol − o que, e por que. Disponıvel em:
<http://br−linux.org/artigos/ldap intro.htm>.
[LCC/UFMG, 2005] LCC/UFMG, L. d. C. C. . U. F. d. M. G. (2005.). LDAP. Dis-
ponıvel em: <http://www.rnp.br// arquivo/sci/2004/curso LDAP.pdf>.
[Lozano, 2005] Lozano, F. (2005). Integracao de rede com diretorios LDAP. Disponıvel
em: <http://labbi.uesc.br/apostilas/revista do linux/025/rede.html>.
[MacIsaac, 2005] MacIsaac, M. (2005). Directory Solutions Using OpenLDAP. SHARE.
[Marshall, 2005] Marshall, B. (2005). Introduction to LDAP, pages 1–127.
[Martines, 2002] Martines, Carla Guimaraes; Lima, E. C. d. (2002). Estudo da
configuracao do protocolo LDAP visando a replicacao do modulo catalogo do soft-
ware direto.
103
[Martins, 2005] Martins, D. N. (2005.). LDAP: Uso e aplicacoes. Disponıvel em:
<http://www.rnp.br/ arquivo/sci/2000/ldap.pdf>.
[Microsoft, 2005] Microsoft (2005). Active directory. Disponıvel em:
<http://www.dcc.ufmg.br/pos/html/spg2002/anais/lamarque/lamarque.html>.
[Morgan, 2005] Morgan, B. L. B. (2005). Identifiers, authentication,
and directories: Best practices for higher education. Disponıvel em:
<http://sites.grude.ufmg.br/QuickPlace/lcc/PageLibrary83256A0900141D08.nsf/$
defaultview/A7599465F72F8C9A83256A460071E2C7/$File/Identifiers%2C%20Au
thentication%2C%20and
[MOTTA, 2001] MOTTA, Gustavo H. M. B.; FURUIE, S. S. (2001). Um modelo de
autorizacao e controle de acesso para o prontuario eletronico de pacientes em ambi-
entes abertos e distribuıdos. Revista Brasileira de Engenharia Biomedica, 17(3):141–
150.
[Naguel, 2005] Naguel, Frederico Fernando; Fernandes, E. C. (2005).
LDAP - lightweight directory access protocol. Disponıvel em:
<http://www.ldap.liceu.com.br/index.html>.
[NBR, 2001] NBR, I. . (2001). Tecnologia Da Informacao: Codigo de Pratica Para
a Gestao Da Seguranca Da Informacao. ABNT - Associacao Brasileira de Normas
Tecnicas, Rio de Janeiro.
[Pininga, 2005] Pininga, Jose Edmir; Silva, J. E. D. T. J. (2005). Trabalho sobre OpenL-
DAP. Disponıvel em: <http://www.geocities.com/SoHo/1062/>.
[Pohlman, 2003] Pohlman, M. (2003). LDAP Metadirectory Provisioning Methodology:
A Step by Step Method to Implementing LDAP Based Metadirectory Provisioning &
Identity Management Systems. Writer’s Showcase.
[PUCPR, 2005] PUCPR (2005). Pergamum. Disponıvel em:
<http://www.pergamum.pucpr.br/pergamum/php/index.php>.
104
[Quirino, 2005] Quirino, Felipe Silva; Junior, H. S. d. F. (2005). Autenticacao distribuıda
de sistemas hıbridos e servicos de rede baseada em servico de diretorios. Disponıvel
em: <http://www.redes.unb.br/PFG.202004.pdf>.
[Rhee, 2003] Rhee, M. Y. (2003). Internet Security: Cryptographic Principles, Algo-
rithms and Protocols. John Wiley & Sons Ltd.
[RNP, 2005] RNP, R. N. d. E. e. P. (2005.). Public key cryptography for initial authenti-
cation in kerberos. Disponıvel em: <http://www.rnp.br/ietf>.
[Schneier, 2001] Schneier, B. (2001). Seguranca.Com, Segredos e Mentiras Sobre a
Protecao Na Vida Digital. Editora Campus Ltda, Rua: Sete de Setembro, 111 − 16
andar - Rio de Janeiro/RJ.
[Semola, 2003] Semola, M. (2003). Gestao Da Seguranca Da Informacao: Uma Visao
Executiva. Editora Campus Ltda, Rio de Janeiro/RJ.
[Soares, 1995] Soares, Luiz Fernando Gomes; Lemos, G. C. S. (1995). Redes de Com-
putadores: Das LANs, MANs e WANs As Redes ATM. 2. Ed. Campus, Rio de Janeiro.
[Souza, 2005] Souza, L. V. (2005). Servico descentralizado de
localizacao de recursos em redes de computadores. Disponıvel em:
<http://www.dcc.ufmg.br/pos/html/spg2002/anais/lamarque/lamarque.html>.
[Takahashi, 2005] Takahashi, Hugo Leonardo; Hattori, K. H. (2005). In-
teligencia artificial voltada a educacao: Glossario. Disponıvel em:
<http://www.din.uem.br/ia/a correl/iaedu/glossario.htm>.
[Tanenbaum, 1997] Tanenbaum, A. S. (1997). Redes de Computadores. Rio de Janeiro,
3rd edition.
[TUTTLE, 2005] TUTTLE, S. e. a. (2005). Understan-
ding LDAP: Design and implementation. Disponıvel em:
<http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf>.
105
[UDESC, 2005] UDESC (2005). Centro de ciencias tecnologicas - CCT. Disponıvel em:
<www.joinville.udesc.br>.
[UFRGS, 2005] UFRGS, I. d. I. (2005). Projeto direto: Siste-
mas avancados para comunicacao eletronica. Disponıvel em:
<http://www.inf.ufrgs.br/procpar/direto/#>.
[Vitorio, 2005] Vitorio, Marcelo Martinho; Luz, S. E. B. D. (2005.).
Servico de diretorio LDAP: Estrutura e funcionamento. Disponıvel em:
<http://twiki.im.ufba.br/pub/GESI/WebHome/GESI apresentacao LDAP release
candidate.ppt>.
[Voglmaier, 2004] Voglmaier, R. (2004). The ABCs of LDAP: How to Install, Run, and
Administer LDAP Services. Auerbach Publications.
[Wanderley, 2005] Wanderley, Euricelia Viana; Moura, M. T. (2005). A integracao de
LDAP e certificados digitais em uma polıtica de seguranca. Disponıvel em: <http://
www.rnp.br/newsgen/0011/ldap.html#ng-resumo>.
Apendice A
Plano de Trabalho
Neste anexo esta contido o Plano de Trabalho, da primeira e segunda
parte do Trabalho de Conclusao de Curso (TCC), aprovado no primeiro semestre do
ano de 2005. A inclusao deste plano visa esclarecer detalhes de execucao, eliminar re-
dundancias de descricoes e estabelecer uma correlacao entre o planejado e desenvolvido
pela orientanda.
Apendice B
Cronograma do Trabalho
Neste anexo estao contidas as etapas do Cronograma de Trabalho, da
primeira e segunda parte do Trabalho de Conclusao de Curso (TCC), aprovado no pri-
meiro semestre do ano de 2005. A inclusao deste cronograma visa deixar clara a relacao
existente entre as etapas1 que foram previstas e as que foram realizadas.
Figura B.1: Cronograma Geral: Previsto X Realizado
1Verificar a descricao das etapas no Apendice A.
Apendice C
Configuracao do OpenLDAP no Linux
Neste anexo estao contidas as informacoes necessarias para a configu-
racao do OpenLDAP na distribuicao do Linux Kurumin versao 5.0. A incluso desde visa
possibilitar a visualizacao de forma pratica de configurar e trabalhar com um servidor
LDAP.
Apos a instalacao do Kurumin deve ser feita a atualizacao dos pacotes
no apt-get atraves do comando:
• sudo apt-get update
Finalizando esta etapa, verifique quais dos pacotes estao apresentando
erro e comente-os no arquivo:
• etc/apt/sources.list
Com o linux ja instalado e com os pacotes atualizados, deve-se instalar
o Apache-php4 e o MySQL que se encontra no Centro de Controle do Kurumin/Instalar
e Configurar Servidores.
Depois de instalados o Apache e o Mysql instale o OpenLdap, que nessa
distribuicao recebe o nome do pacote gforge-ldap-openldap, com o comando:
• sudo apt-get install gforge-ldap-openldap
109
A fim de facilitar a criacao dos grupos e usuarios no OpenLDAP, pode-
se utilizar o phpldapadmin que e uma interface grafica. Para instala-lo execute o comando:
• sudo apt-get install phpldapadmin
Para acessar o phpldapadim digite o endereco:
• http://127.0.0.1/phpldapadmin
Apendice D
Tela de Dados do SigmaWeb
Neste anexo esta contida a tela principal do SigmaWeb, onde as infor-
macoes estao dispostas e organizadas de acordo com o menu a esquerda. Tais dados re-
presentam informacoes do contexto academico, da Univesidade, para professores, alunos
e funcionarios.
Figura D.1: Tela de Dados do SigmaWeb
Apendice E
Telas de cadastro do Pergamum
Neste anexo estao contidas as telas do Sistema Pergamum, as quais
contem os dados necessarios para o cadastro de usuarios. Tais dados sao caracterizadores
e geram uma identidade para cada novo cadastro.
Figura E.1: Tela Validade do Cadastro de Usuario do Pergamum
112
Figura E.2: Tela Area de Conhecimento do Cadastro de Usuario do Pergamum
Figura E.3: Tela Base de Dados do Cadastro de Usuario do Pergamum
113
Figura E.4: Tela Dados Responsavel do Cadastro de Usuario do Pergamum
Figura E.5: Tela Unidade Organizacional do Cadastro de Usuario do Pergamum
114
Figura E.6: Tela Emprestimo - Senha do Cadastro de Usuario do Pergamum
Apendice F
Ficha de Pre-Empenho
Neste anexo esta contida a Ficha de Pre-Empenho que e utilizada por
interessados em realizar uma solicitacao de um determinado empenho. Esta serve para
demonstrar as informacoes necessarias para tal fim, as quais serao adicionadas no Sistema
de Empenho.
Figura F.1: Ficha com as informacoes necessarias para realizar uma solicitacao de empenho.
Apendice G
Telas de Cadastro de Empenho
Este anexo apresenta as telas do Sistema de Empenho, onde sao ca-
dastradas todas as informacoes necessarias para realizar a solicitacao de empenho. Este
sistema, disponibilizado pela Universidade, busca facilitar o controle de pedidos e de
pagamentos realizados.
Figura G.1: Tela de Dados do Sistema de Empenho
117
Figura G.2: Tela de Dados do Sistema de Empenho
Apendice H
Telas do Sistema de Viagens
Neste anexo estao contidas as telas do Sistema de Viagens, as quais pos-
sibilitam o cadastro de solicitacoes de recursos financeiros. Com base nestas informacoes,
as propostas sao analisadas e o auxılio financeiro concedido ou nao.
Figura H.1: Tela de Identificacao do Sistema de Viagens
119
Figura H.2: Tela de Solicitacao do Sistema de Viagens
Apendice I
Tela da Intranet
Este anexo apresenta a tela principal da Intranet, na qual estao dispostos
os servicos existentes. Este sistema, disponibilizado pela Universidade, busca atender os
seus usuarios com suas inumeras funcionalidades.
Figura I.1: Tela de servicos disponibilizados pela Intranet
Apendice J
Telas do Cadastro do Sistema de Bolsa
Este anexo contem as telas de cadastro do Sistema de Bolsas de Apoio
Discente. Tais informacoes sao necessarias para caracterizar aspectos relevantes diante as
condicoes financeiras e as necessidades de bolsa de cada pessoa.
Figura J.1: Tela de Cadastro do Sistema de Bolsa
122
Figura J.2: Tela de Identificacao do Sistema de Bolsa
Figura J.3: Tela de Dados do Sistema de Bolsa
Apendice K
Ficha de Dados
Neste anexo esta contida a Ficha de Dados que e utilizada por inte-
ressados em adquirir algum dos servicos disponibilizados pela UDESC. As informacoes
contidas nela sao utilizadas pelo Suporte da Universidade para realizar cadastros e dispor
os servicos.
Figura K.1: Ficha de Dados para Solicitacao de Servicos
Apendice L
Telas de Cadastro de Solicitacao de
ADSL
Este anexo apresenta as telas do Sitema de Solicitacao de ADSL. Tais
informacoes sao preenchidas para requisitar a disponibilizacao do servico de ADSL que
a Universidade fornece.
Figura L.1: Termo de Acordo
125
Figura L.2: Tela de Cadastro de Solicitacao de ADSL
Apendice M
Implementacao do modelo proposto
Este anexo apresenta a tela com as configuracoes do modelo proposto,
que pode ser representadas pela Figura 5.6. Esta estrutura foi desenvolvida buscando
contemplar os possıveis usuarios do CTT/UDESC e as funcionalidades do OpenLDAP e
da interface grafica phpldapadmin.
Figura M.1: Tela de demonstracao da implementacao do que foi proposto
