Você está na página 1de 73

FABRCIO RODRIGO DE SOUZA LEO

ESTUDO DA API JAVA NAMING DIRECTORY INTERFACE NO ACESSO E MANIPULAO DE DADOS DO ACTIVE DIRECTORY

Palmas-TO 2006

FABRCIO RODRIGO DE SOUZA LEO

ESTUDO DA API JAVA NAMING DIRECTORY INTERFACE NO ACESSO E MANIPULAO DE DADOS DO ACTIVE DIRECTORY

Monografia apresentada como requisito parcial da disciplina Trabalho de Concluso de Curso em Sistemas de Informao I (TCC I) e Trabalho de Concluso de Curso em Sistemas de Informao II (TCC II), do curso de Sistemas de Informao, orientado pelo Prof. M.Sc. Ricardo Marx Costa Soares de Jesus.

Palmas-TO 2006

FABRCIO RODRIGO DE SOUZA LEO

ESTUDO DA API JAVA NAMING DIRECTORY INTERFACE NO ACESSO E MANIPULAO DE DADOS DO ACTIVE DIRECTORY

Monografia apresentada como requisito parcial da disciplina Trabalho de Concluso de Curso em Sistemas de Informao I (TCC I) e Trabalho de Concluso de Curso em Sistemas de Informao II (TCC II), do curso de Sistemas de Informao, orientado pelo Prof. M.Sc. Ricardo Marx Costa Soares de Jesus.

BANCA EXAMINADORA

Prof. M.Sc Ricardo Marx Costa Soares de Jesus


Centro Universitrio Luterano de Palmas

Prof. M.Sc Fernando Luiz de Oliveira


Centro Universitrio Luterano de Palmas

Prof. M.Sc Jackson Gomes de Souza


Centro Universitrio Luterano de Palmas

Palmas-TO 2006

SUMRIO

1 2

INTRODUO.................................................................................................................................... 10 REVISO DE LITERATURA ........................................................................................................... 12 2.1 DIRETRIOS .................................................................................................................................. 12 2.2 SERVIO DE DIRETRIO ................................................................................................................ 13 2.3 SERVIO DE NOMES ...................................................................................................................... 13 2.4 SCHEMA (ESQUEMA)..................................................................................................................... 14 2.5 PROTOCOLO X.500 E DAP ............................................................................................................ 15 2.6 PROTOCOLO LDAP ....................................................................................................................... 16 2.7 ACTIVE DIRECTORY ...................................................................................................................... 17 2.7.1 Objetos..................................................................................................................................... 18 2.7.2 Contas de Usurios ................................................................................................................. 19 2.7.3 Contas de Computadores......................................................................................................... 20 2.7.4 Grupos ..................................................................................................................................... 20 2.7.5 Unidades Organizacionais ...................................................................................................... 21 2.7.6 Pastas Compartilhadas............................................................................................................ 22 2.7.7 Impressoras Compartilhadas................................................................................................... 23 2.8 TERMOLOGIA ................................................................................................................................ 23 2.9 FLAGS (BANDEIRAS) DE CONTROLE DA CONTA ............................................................................ 24 2.10 OPERAES SOBRE O ACTIVE DIRECTORY .................................................................................... 25 2.10.1 Autenticao ....................................................................................................................... 26 2.10.2 Criao de Contas de Usurios .......................................................................................... 26 2.10.3 Criao de Contas de Computadores ................................................................................. 27 2.10.4 Criao de Grupos.............................................................................................................. 27 2.10.5 Compartilhando e Publicando Pastas ................................................................................ 28 2.10.6 Compartilhando e Publicando Impressoras ....................................................................... 28 2.10.7 Localizar Objetos................................................................................................................ 29 2.11 API JAVA NAMING AND DIRECTORY INTERFACE .......................................................................... 30 2.11.1 Arquitetura JNDI ................................................................................................................ 32 2.11.2 Pacotes................................................................................................................................ 32

MATERIAL E MTODOS ................................................................................................................ 34 3.1 LOCAL E PERODO ......................................................................................................................... 34 3.2 MATERIAIS .................................................................................................................................... 34 3.2.1 Hardware................................................................................................................................. 34 3.2.2 Softwares ................................................................................................................................. 35 3.2.3 Fontes Bibliogrficas .............................................................................................................. 35 3.3 METODOLOGIA.............................................................................................................................. 35

RESULTADOS E DISCUSSO ......................................................................................................... 37 4.1 4.2 4.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.6 4.6.1 4.6.2 ACESSANDO UM SERVIO DE DIRETRIOS .................................................................................... 39 ADICIONANDO OBJETOS NO DIRETRIO ........................................................................................ 43 REMOVENDO OBJETOS DO DIRETRIO .......................................................................................... 46 MODIFICANDO OBJETOS/ATRIBUTOS DO DIRETRIO .................................................................... 47 BUSCANDO OBJETOS/ATRIBUTOS DO DIRETRIO ......................................................................... 48 Busca Simples.......................................................................................................................... 49 Busca com Filtros.................................................................................................................... 50 Busca com Escopo ................................................................................................................... 52 ACESSO AO SERVIO DE DIRETRIOS COM CONEXO SEGURA ....................................................... 53 SSL (Secure Socket Layer)....................................................................................................... 54 TSL (Transport Layer Security)............................................................................................... 55

vi

4.6.3 Acesso ao Servio de Diretrios.............................................................................................. 56 4.7 AUTENTICAO UTILIZANDO A BASE DE DADOS DO ACTIVE DIRECTORY ..................................... 58 4.7.1 SISGAP .................................................................................................................................... 58 4.7.2 Migrando a Aplicao ............................................................................................................. 60 5 CONSIDERAES............................................................................................................................. 68 5.1 5.2 6 CONSIDERAES FINAIS ............................................................................................................... 68 PROPOSTA DE TRABALHOS FUTUROS ............................................................................................ 69

REFERNCIAS BIBLIOGRFICAS............................................................................................... 70

vii

Lista de Figuras
Figura 1 - Esquema do modelo funcional do servio de diretrio do X.500...................... 15 Figura 2 - Objetos e Atributos no Active Directory........................................................... 19 Figura 3 - O usurio herda as permisses de grupo.......................................................... 21 Figura 4 - Arquitetura JNDI............................................................................................... 31 Figura 5 - Usurios distintos para cada aplicao............................................................ 38 Figura 6 - Usurio nico para todos os aplicativos........................................................... 39 Figura 7 - Acessando servio de diretrios........................................................................ 41 Figura 8 - Criando usurio................................................................................................ 44 Figura 9 - Criando grupo................................................................................................... 45 Figura 10 - Removendo usurio......................................................................................... 46 Figura 11 - Modificando objetos........................................................................................ 47 Figura 12 - Busca simples.................................................................................................. 50 Figura 13 - Busca com filtros............................................................................................. 50 Figura 14 - Busca com escopo............................................................................................ 53 Figura 15 - Arquitetura TCP/SSL....................................................................................... 54 Figura 16 Acesso atravs de conexo segura.................................................................. 57 Figura 17 - Autenticao atravs do banco de dados........................................................ 61 Figura 18 - Acessando o Servio de Diretrios.................................................................. 63 Figura 19 - Autenticando no Servio de Diretrios........................................................... 63 Figura 20 - Buscando Usurio........................................................................................... 64 Figura 21 - Buscando nvel de acesso................................................................................ 65 Figura 22 Buscando cdigo do usurio.......................................................................... 66

viii

Lista de Tabelas

TABELA 1: TERMOS DO ACTIVE DIRECTORY ......................................................................................... 24 TABELA 2: ATRIBUTOS DE CONTROLE.................................................................................................... 25 TABELA 3: CRONOGRAMA DE ATIVIDADES............................................................................................ 36 TABELA 4: SMBOLOS LGICOS ............................................................................................................... 51

ix

Lista de Abreviaturas
AD - Active Directory API - Application Programming Interface CEULP - Centro Universitrio Luterano de Palmas CORBA - Common Object Request Broker Architecture DAP - Directory Access Protocol DIT - Directory Information Tree DNS - Domain Name System DSA - Directory Service Agent DUA - Directory User Agent IP - Internet Protocol ITU - International Telecommunications Union JNDI - Java Naming and Directory Interface JSP - Java Server Pages Keytool - Key and Certificate Management Tool LDAP - Lightweight Directory Access Protocol MD - Message Digest NIS - Network Information Service RMI - Remote Method Invocation SASL - Simple Authentication and Security Layer SDK - Software Development Kit SP/SPI - Service Provinders Interface TLS - Transport Layer Security SISGAP - Sistema de Gerenciamento Acadmico e Pessoal ULBRA - Universidade Luterana do Brasil URL - Universal Resource Locator

RESUMO
Os servios de diretrios so bases de dados que se caracterizam pela escalabilidade na realizao de consultas simultneas. Porm, no so eficazes em ambientes que necessitam de grandes volumes de atualizaes de dados. Essas bases de dados quase sempre trabalham em uma aplicao especfica, no interagindo com os demais sistemas. Por isto, elas acabam trabalhando paralelamente a outras bases de dados e muitas vezes geram redundncias e inconsistncias nos dados. O Java Naming and Directory Interface uma API que surge como alternativa para que aplicaes Java acessem e gerenciem dados dos servios de nomes e diretrios. Dessa forma, os servios de diretrios podero passar a interagir com outras bases de dados ou aplicaes, acabando com a necessidade de possuir mais de uma base de dados que armazene as mesmas informaes, diminuindo a probabilidade de ocorrncia de redundncias e inconsistncias de dados.

Palavras-chave: API JNDI, Acesso a servio de diretrio, Active Directory;

1 INTRODUO
Atualmente os usurios possuem a necessidade de interagir com vrios tipos de aplicaes em um ambiente corporativo, como aplicativos, servidores de e-mail, servidores de rede, entre outros. Vrios desses sistemas armazenam em suas bases de dados, as mesmas informaes como: nome, endereo, e-mail e principalmente, credenciais (usurio e senha) para autenticar o usurio no sistema. Essas informaes repetidas geram redundncia de dados, alm de obrigar ao usurio a necessidade de obter e memorizar uma nova credencial de acesso para cada aplicativo que o mesmo acessar. Outro ponto a ser analisado a atualizao dessas informaes, que nem sempre que so atualizadas em uma determinada base de dados, tem a mesma atualizao refletida nas demais bases, gerando a inconsistncia de dados. Esse tipo de problema pode ser sanado atravs da utilizao de um repositrio de dados nico para todas essas aplicaes, fazendo com que elas utilizem a mesma base de dados para armazenarem informaes comuns entre elas. Atravs da centralizao dos dados em um repositrio nico, se facilita o gerenciamento das informaes e diminui a probabilidade da existncia de redundncias e inconsistncias. Para isso, a API Java Naming and Directory Interface disponibiliza meios para que aplicaes Java acessem e gerenciem servios de diretrios, possibilitando assim a utilizao de um diretrio para vrias aplicaes. Atravs da API h a possibilidade de utilizar um repositrio de dados como uma base nica de credenciais de logon, permitindo que os usurios se utilizem apenas de um nico nome de usurio e senha para acessar a diversas aplicaes. Esse trabalho prope o estudo da API JNDI como interface para o acesso e gerenciamento dos dados armazenados nos servios de diretrios, em especial, o Active Directory, que ser o servio de diretrios utilizado no desenvolvimento desse trabalho. Outro ponto a ser desenvolvido por esse trabalho a migrao de uma aplicao Java para

11

que a mesma possa autenticar seus usurios atravs de um servio de diretrios, o Active Directory do Windows Server2003.

2 REVISO DE LITERATURA
Nessa seo sero apresentados os conceitos bsicos utilizados para o desenvolvimento desse trabalho. Entre os contedos abordados esto Diretrios, Servios de Diretrios, Protocolos X.500 e LDAP, Active Directory e API JNDI, com o intuito de proporcionar o conhecimento necessrio para o entendimento do trabalho. Esses conceitos sero apresentados nas sees seguintes.

2.1 Diretrios
Um Diretrio uma base de dados especfica destinada ao armazenamento de grande quantidade de informaes de forma hierrquica sobre um determinado domnio. A forma hierrquica de armazenamento faz com que as buscas realizadas tenham maior desempenho na realizao de consultas simultneas. Para Gouveia (2005, p. 6,

http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf) Um Diretrio uma base de dados especializada definida de forma hierrquica, otimizado para leitura, suportando sofisticados mtodos de pesquisa, com o objetivo de proporcionar uma resposta rpida a um enorme volume de consultas e onde so armazenadas informaes estticas de objetos. A base de dados estruturada hierarquicamente similar a uma rvore, onde se localiza o n principal, conhecido como n raiz, de onde partem as ramificaes, mais conhecidas como ns folhas. As estruturas dos diretrios aliadas aos mtodos de pesquisas eficientes favorecem a realizao de consultas simultneas, sendo que a mesma eficincia no observada quando h um alto nmero de operaes de escrita na base de dados. Portanto, a utilizao de diretrios para armazenamento de informaes vivel em

13

ambientes que realizam grande nmero de consultas simultneas aliadas a uma baixa atualizao da base de dados.

2.2 Servio de Diretrio


O Servio de Diretrio uma aplicao (cliente) que tem como finalidade permitir que o usurio manipule a base de dados do diretrio (servidor). Esse servio deve dispor de mtodos que permitam a insero, remoo, pesquisa, atualizao dos dados do diretrio. Para Oliveira, Carissimi e Toscani (2004, p. 198-199) o conceito de servio de diretrio o conjunto de funes para criao, armazenamento e recuperao de informaes de um diretrio. O servio de diretrio deve permitir que os dados do diretrio sejam manipulados. Para isso o servio de diretrio deve disponibilizar mtodos que permitam o acesso, criao, modificao e excluso dos objetos dos diretrios. Em alguns casos os diretrios podem realizar a funo de autenticao de usurios para acessar alguma aplicao ou dispositivo. Segundo Gouveia (2005, p. o servio 7, de

http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf) diretrio deve possuir as seguintes caractersticas:

ser flexvel, pois deve permitir que vrios tipos de informaes sejam inseridas na base de dados. ser seguro, possuindo mecanismos para autenticao tanto para acesso interno quanto para acesso externo. ser escalvel e adaptvel, mesmo com o aumento significativo no nmero de registros, o servio deve continuar eficaz. ser extensvel, pois deve permitir alteraes na sua estrutura conforme as necessidades venham a surgir.

2.3 Servio de Nomes


O Servio de Nomes um servio presente no protocolo LDAP (Lightweight Directory Access Protocol) que consiste na associao de nomes a um determinado

14

recurso. O servio de nome o lugar onde um nome resolvido, ou seja, associado outra informao. Um exemplo de servio de nomes o servio DNS (Domain Name System), que associa o nome da mquina ao endereo IP (informao) correspondente. Dessa forma, se permite que seja recuperada uma informao atravs do nome que a representa. Segundo Panissa (2002, p. 44) o servio DNS um banco de dados que mapeia nomes de host a endereos IP. Um dos benefcios disso que nomes so muito mais simples de lembrar que endereos IP e os nomes so muito mais resistentes a mudanas que os endereos IP. Quando o servidor acessado, o servio de nomes associa o nome do host a um endereo de IP. Por exemplo, quando um site acessado atravs do endereo (nome), o servio de nomes associa o nome que foi informado ao seu endereo IP, e retorna o endereo IP (informao) correspondente. Dessa forma ao digitar o endereo http://www.ulbra-to.br o servio de nomes DNS retorna a informao 200.199.199.66.

2.4 Schema (Esquema)


Para manter a consistncia dos dados do diretrio, o LDAP adota o Schema (Esquema), que permite estruturar os dados que sero inseridos no diretrio. Essa estruturao feita de forma a adaptar os tipos de dados aceitos no diretrio s necessidades impostas pela aplicao na qual ser utilizado o diretrio. Atravs do Schema tambm possvel manter o servio de diretrios flexvel, modificando a estrutura do mesmo conforme venha surgir necessidades de alterao. Para Ortiz (2001, p. 200) o Schema pode ser definido como [...] um conjunto de regras que estabelece a criao de objetos no Active Directory. O esquema guarda todos os atributos dos objetos. Segundo Gouveia, (2005, p. 7,

http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf), o Schema define: as object classes (classes de objetos) que sero aceitas no diretrio; quais os atributos da object classes; os possveis valores para os atributos.

15

Os atributos podem ser obrigatrios ou opcionais, devendo ser especificado no Schema. Os valores (dados) que no seguirem o Schema do diretrio no podero ser inseridos no diretrio.

2.5 Protocolo X.500 e DAP


O protocolo X.500 um servio de diretrio criado na dcada de 80. Ele foi criado com o objetivo de fazer a ligao entre diretrios locais e ainda promover a formao de diretrios distribudos (aplicaes cliente-servidor). O protocolo X.500 se caracterizava por ser formado por dois agentes, o DUA (Directory User Agent) e o DSA (Directory Service Agent). Para Gouveia (2005, p. 3-4,

http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf), o X.500 pode ser definido como um Servio de Diretrio universal desenvolvido pela ITU (International Telecommunications Union), com o objetivo de definir a ligao entre Servios de Diretrios locais para assim formar um diretrio global distribudo.

Figura 1 - Esquema do modelo funcional do servio de diretrio do X.500. (Fonte: GOUVEIA, 2005, http://www.ldap.org.br/modules/ldap/files)

Como pode ser observado na Figura 1, o X.500 est embasado em dois agentes, DUA e DSA. O DUA a aplicao cliente por onde os usurios manipulam as entradas no diretrio e o DSA a aplicao servidora que gerencia o diretrio juntamente com o DIT (Directory Information Tree) e provem o servio s aplicaes clientes. Para haver a

16

interao entre os agentes DUA e DAS, foi desenvolvido o protocolo DAP (Directory Access Protocol), que era um protocolo que exigia um custo computacional muito alto para a poca. [...] o resultado foi um servio de diretrio bastante complexo e de custo computacional incompatvel com equipamentos menores. Era muito difcil rodar clientes X.500 nos microcomputadores disponveis na poca (ISQUIERDO, 2001,

http://www.teses.usp.br/teses/disponiveis/45/45134/tde-28052003100121/publico/gustavo.pdf). O protocolo DAP era considerado complexo, o que exigia um custo computacional elevado para poca. Com isso, os esforos para a criao do protocolo foram parados, pois na poca no havia disponibilidade de recursos computacionais que eram exigidos para a utilizao do protocolo. Devido ao alto poder de processamento exigido pelo protocolo em aplicaes clientes, foi necessrio o desenvolvimento de um novo protocolo que viesse a sanar tais necessidades. A partir desse momento, no final dos anos 80 e incio dos anos 90, teve inicio o aperfeioamento do protocolo X.500, que futuramente viria a se chamar LDAP (Lightweight Directory Access Protocol).

2.6 Protocolo LDAP


Com o objetivo de criar um protocolo completo e que tivesse uma maior compatibilidade com os recursos computacionais da poca, pesquisadores da Universidade de Michigan iniciaram os estudos para a criao de um protocolo com tais caractersticas. No ano de 1993 foi ento criado o protocolo LDAP, baseado no padro X.500, que viria a substituir o protocolo DAP. O modelo de desenvolvimento do LDAP consistia na criao de grupos de discusso na Internet, que alm de divulgar o protocolo, passara tambm a aperfeioar constantemente o mesmo, fazendo com que o protocolo passasse de uma alternativa ao DAP para uma opo completa de servio de diretrio e na seqncia passaria a ser maioria entre desenvolvedores.

Boa parte desse trabalho foi realizado na Universidade de Michigan, qual estavam vinculados vrios membros de grupo OSI-DS. [...] O desenvolvimento foi acompanhado por

17

usurios e desenvolvedores do mundo inteiro. Com a popularizao do protocolo, o LDAP deixou de ser uma mera alternativa ao DAP do X.500 e ganhou status de servio de diretrio completo, passando a competir com o X.500. (ISQUIERDO, http://www.teses.usp.br/teses/disponiveis/45/45134/tde28052003-100121/publico/gustavo.pdf) 2001,

Segundo

Gouveia

(2005,

p. a

3-4, grande

http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf),

diferena entre o LDAP e as Bases de Dados Relacionais, que no LDAP a informao est guardada seguindo uma estrutura em rvore, raramente se efetuam atualizaes, est otimizado para responder a um grande nmero de pesquisas e tm um alto nvel de segurana. O protocolo LDAP se destaca entre os servios de diretrios pela eficincia em pesquisas, proporcionando respostas rpidas mesmo quando submetido a um grande nmero de consultas simultneas. Essa superioridade deve-se aos mtodos de pesquisas eficientes e do alto poder de leitura do servio de diretrio. Essa mesma eficcia encontrada nos diretrios para a realizao de pesquisas no mantida quando h alterao constante dos dados do diretrio, fazendo com que o mesmo perca consideravelmente a escalabilidade.

2.7 Active Directory


O Active Directory um servio de diretrio desenvolvido pela Microsoft. Ele foi baseado no protocolo LDAP, e surgiu juntamente com o lanamento do Windows 2000 Server e que tambm est presente, com alguns incrementos, no Windows 2003 Server. Segundo Hayday (2000, p.103-104) O Active Directory tambm fornece uma viso centralizada quando ele gerencia os relacionamentos entre objetos e recipientes, tornando os recursos mais fceis de serem encontrados, gerenciados e utilizados em uma rede altamente distribuda [...].

18

O Active Directory um dos principais aplicativos presentes no Windows Server. Em sua essncia uma base de dados que armazena grande parte dos dados da rede, permitindo gerenciar de forma centralizada grandes redes de computadores e seus objetos e recursos. Atravs do Active Directory possvel realizar o controle de acesso dos usurios, passando pelo gerenciamento das estaes de trabalho, servidores, impressoras, recursos, etc. Os dados (recursos) armazenados no Active Directory recebem o nome de objetos (objects). Esses objetos podem ser usurios, computadores, impressoras, etc. Cada objeto pode receber atributos que o caracterizam. Por exemplo, no caso do objeto que representa um usurio, pode ter vrios atributos, como nome, endereo, e-mail, descrio.

2.7.1 Objetos

Segundo Hayday (2000, p.112-120), Os objetos do Active Directory so entidades que formam a rede. Um objeto um conjunto de diferentes atributos que representa algo concreto, como um usurio ou computador. Tudo que pode ser localizado dentro do Active Directory um objeto. Os objetos so instncias de qualquer usurio, computador, recurso ou servio localizado dentro do Active Directory. Cada objeto possui um conjunto de atributos ou propriedades especficas, que possuem a funo de nomear e descrever determinado recurso de rede. Na Figura 2 h dois tipos de objetos, os usurios (Users) e os computadores (Computers). Como podem ser observados, esses objetos possuem como atributos Primeiro Nome (First Name), ltimo Nome (Last Name) e Nome do Computador (Computer Name) respectivamente. Para armazenar as informaes dos objetos criada no Active Directory uma instncia do mesmo, onde so inseridos os respectivos atributos que o descrevem.

19

Figura 2 - Objetos e Atributos no Active Directory . (Fonte: PEREIRA, p. 1, www.dei.isep.ipp.pt/~npereira/aulas/asi1/04/misc/ADintro.pdf)

Os principais objetos existentes no Active Directory so: Contas de Usurios; Contas de Computadores; Grupos; Unidades Organizacionais; Pastas Compartilhadas; Impressoras.

2.7.2 Contas de Usurios As contas de usurios so criadas para os usurios serem identificados e poderem ter acesso aos recursos do domnio. Ao criar uma conta de usurio, automaticamente criado um objeto para representar o mesmo no Active Directory que deve conter basicamente o nome de logon (deve ser nico) e senha (caso requerido). Outras informaes (atributos) tambm podem ser inseridas como nome, sobrenome, endereo, telefone, e-mail, etc. Segundo Hayday (2000, p. 120), Um objeto usurio um objeto principal de segurana no diretrio. Um usurio pode efetuar logon para a rede com essas credenciais e a permisso de acesso pode ser fornecida aos usurios.

20

Os utilizadores da rede atravs de suas credenciais, usurio e senha, podem autenticar-se no computador atravs da rede e obter o acesso aos recursos e servios que lhes foram concedidos. Os recursos ao qual o mesmo poder ter acesso so definidos pelo administrador da rede. As contas de usurios tambm so importantes para a utilizao do sistema de auditoria do Windows Server, permitindo registrar no log de auditoria quais os recursos e servios foram acessados e por quais usurios foram acessados.

2.7.3 Contas de Computadores Todas as estaes de trabalho que possuem o sistema operacional Windows 2000 Professional, Windows NT 4.0 Workstation ou Windows XP Professional e que fazem parte de um domnio possuem uma conta de computador no Active Directory. Atravs dessa conta possvel conceder ou negar permisses de acesso para os usurios. Computadores que operam com o Windows 95/98/Me, mesmo que autentiquem no Active Directory no possuem uma conta prpria cadastrada no mesmo. Segundo Hayday (2000, p. 73) uma conta de computador tem como propsito fornecer um meio de se autenticar e auditorar o acesso do computador rede e aos recursos de domnio. Atravs das contas de computadores armazenam-se informaes sobre o mesmo e possibilitam permitir ou negar acesso aos recursos do mesmo. Dessa forma, os objetos que representam os computadores so mais uma forma de gerenciar os recursos da rede.

2.7.4 Grupos Os grupos dentro do Active Directory so agrupamentos de recursos em classes que compartilham alguma caracterstica em comum, quanto ao tipo ou mesmo pelo escopo. Existem grupos que so definidos atravs de seu tipo como o caso de grupos de usurios ou computadores. Os grupos tambm podem ser divididos a partir da semelhana de finalidade, como o caso dos usurios avanados e usurios administradores. Para Hayday (2000, p. 120) os grupos podem conter usurios, computadores e outros grupos. Os grupos simplificam o gerenciamento de um grande nmero de objetos.

21

Existem dois tipos de grupos no Active Directory, so eles: grupos de segurana destinados para a concesso de permisses de acesso aos recursos; grupos de distribuio destinados a aplicativos. Exercem a funo de listas. A principal funo dos grupos a delegao de recursos, onde ao invs das atribuies dos recursos de rede ser efetuada individualmente, so organizados grupos de usurios com caractersticas similares e em seguida so delegados ao grupo os recursos computacionais convenientes a ele. Isso pode ser observado na figura 3, onde os recursos so associados ao grupo Contabilidade. Os usurios do setor de Contabilidade possuem o mesmo padro de acesso aos recursos, portanto ao invs de se disponibilizar os recursos individualmente, foram atribudas atravs do grupo referente aos funcionrios do setor de contabilidade, as permisses de acesso relativas aos mesmos. Com isso, se torna o gerenciamento dos recursos mais eficiente para o administrador.

Figura 3 - O usurio herda as permisses de grupo. (Fonte: BATTISTI, p. 5, http://www.juliobattisti.com.br/artigos/windows/ActiveDirectory_p5.pdf)

Algumas caractersticas de grupos: objetos de um grupo herdam todas as permisses associadas ao grupo; um objeto pode estar atribudo a mais de um grupo; um grupo pode ser membro de outro grupo.

2.7.5 Unidades Organizacionais As unidades organizacionais so colees utilizadas para organizar objetos do Active Directory como usurios, grupos, computadores, impressoras que compartilham

22

alguma semelhana administrativa. As unidades organizacionais no armazenam nada fsico, como um usurio. Em vez disso, as unidades organizacionais so utilizadas para organizar os objetos do Active Directory. Um exemplo a criao de uma unidade organizacional que organize os recursos referentes a um departamento de uma empresa. Assim possvel realizar o gerenciamento dos recursos pertencentes ao departamento de forma centralizada. Para Ortiz (2001, p. 200) as unidades organizacionais so containers utilizados para estruturar um domnio. Esses containers podem ser agrupados e conseqente podem conter outros containers, criando uma estrutura hierrquica. Dependendo do ambiente em que as unidades organizacionais so empregadas, elas podem dividir o domnio de acordo com os departamentos existentes em uma determinada empresa. As unidades organizacionais permitem agrupar objetos diferentes que so donos das mesmas caractersticas, em um container. Dessa forma possvel dividir o domnio em grupos que compartilham as mesmas caractersticas, facilitando a administrao dos recursos.

2.7.6 Pastas Compartilhadas

O compartilhamento de pastas uma forma de tornar as pastas e seus respectivos contedos disponveis atravs da rede de computadores. Atravs do compartilhamento o usurio pode tornar um arquivo acessvel a qualquer estao de trabalho alocada na rede. Segundo Hayday (2000, p. 57), os diretrios tem de ser compartilhados para ficarem disponveis para o acesso de clientes da rede. [...] as permisses no nvel de compartilhamento ficam efetivamente na frente das permisses de diretrios e de arquivos para o acesso da rede. Quando uma pasta no ambiente do Windows Server compartilhada, automaticamente criado um objeto do mesmo no Active Directory, que possui uma referncia (aponta) a outro objeto, no caso, o computador ao qual a pasta compartilhada pertence. Esse objeto, como todos os demais do Active Directory, possui um conjunto de atributos que identificam e descrevem a pasta compartilhada. Atravs do compartilhamento os usurios podem ter acesso atravs da rede aos arquivos contidos na pasta desde que possuam os direitos de acesso apropriados.

23

2.7.7 Impressoras Compartilhadas Ao instalar uma impressora em um computador que seja membro de um domnio do Windows Server, o usurio poder public-la no Active Directory, criando assim um objeto relativo impressora no Active Directory. Esse objeto possui seus respectivos atributos que a identificam e descrevem. Dessa forma se tornam mais fcil a localizao e o gerenciamento do recurso. As impressoras de rede so dispositivos compartilhados. Pode-se anex-las a um servidor de arquivos, um servidor de impresso ou uma estao de trabalho local que age como uma impressora remota. [...] No apenas pode-se atribuir mltiplas impressoras fsicas para uma impressora lgica, como tambm se pode atribuir mltiplas impressoras lgicas a uma ou mais impressoras fsicas. (DAVIS, LEWIS, 2000, p. 378-379) Podem ser instalados vrios dispositivos de impresso a uma impressora lgica (driver de impresso), da mesma forma que podem ser instalados vrios drivers para um dispositivo de impresso. Essa propriedade de possibilitar a instalao de vrios drivers para um mesmo dispositivo que possibilita que as impressoras sejam compartilhadas.

2.8 Termologia
O Active Directory adota uma conveno prpria para referenciar as informaes dentro do servio de diretrios. Essa conveno consiste em siglas que so associadas s informaes dos objetos, permitindo que as informaes sejam identificadas. As informaes devem seguir a estrutura de classes e atributos, pr-definida no Schema (esquema) do Servio de Diretrios. Na Tabela 1, sero apresentados os principais termos utilizados no Active Directory acompanhados de suas respectivas denotaes. Para um melhor entendimento dos conceitos, tambm ser relacionada traduo de cada termologia. Atravs da atribuio de valores aos respectivos termos, se define a estrutura da rvore do Servio de Diretrios e a hierarquia entre as classes. Tambm definida a lista de atributos obrigatrios e opcionais para cada classe.

24

Tabela 1: Termos do Active Directory


Termo
DC CN OU givenName initials sn

Termologia
Domain Controler Comon Name Organization United Given Name Initials Surname

Traduo
Controlador de Domnio Nome Comum Unidade Organizacional Primeiro Nome Iniciais Sobrenome/ ltimo nome

Sintaxe
String String String String String String

displayName description telephoneNumber mail

Display Name Description Telephone Number E-Mail

Nome de Exibio Descrio Nmero do telefone E-Mail / Endereo Eletrnico

String String String String

wwwHomePage st postalCode samAccountName userPrincipalName

Home Page Street Postal Code Account Name Principal Name User

Pgina Pessoal Endereo Cdigo Postal Nome de Identificao Principal usurio nome do

String String String String String

logonHours accountExpires pwdLastSet

Logon Hours Account Expires Password Last Insert

Horrio de Logon Cliente Expira Inserir ltima senha

String Date Boolea n

homePhone info department company userAccountControl

Home Telephone Information Departament Company User Account Control

Telefone de Casa Informao Departamento Companhia Controle do usurio

String String String String Flags

2.9 Flags (Bandeiras) de Controle da Conta


Como pode ser observado na Tabela 2, os atributos de controle de conta (userAccountControl) so definidos atravs de cdigos binrios (flags) determinados pela ADSI (Active Directory Services Interfaces). A ADSI define a combinao de valores para cada atributo de controle. Na Tabela 2 so apresentados os principais tipos de atributos de controle, juntamente com os cdigos utilizados para definir cada atributo. Os cdigos apresentados definem os atributos de controle como habilitados.

25

ADSI (Active Directory Service Interfaces) o conjunto de interfaces que a Microsoft fornece como uma ferramenta flexvel para trabalhar com uma variedade de provedores de rede. ADSI oferece ao administrador a capacidade de localizar e gerenciar recursos em uma rede com relativa facilidade, independentemente do tamanho da rede (About Active Directory Service Interfaces, <http://msdn2.microsoft.com/en-

us/library/aa772161.aspx>, traduo nossa).

Tabela 2: Atributos de Controle


Atributo de Controle
UF_PASSWD_NOTREQD

Valor Hexadecimal
0x0020 Senha

Descrio
No

Obrigatria UF_ACCOUNTDISABLE UF_PASSWD_CANT_CHANGE UF_NORMAL_ACCOUNT UF_DONT_EXPIRE_PASSWD UF_PASSWORD_EXPIRED ADS_GROUP_TYPE_GLOBAL_GROUP ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP 0x0001 0x0040 0x0200 0x10000 0x800000 0x0002 0x0004 Conta Desabilitada No Alterar Senha Usurio Comum Senha No Expira Senha Expirada Grupo Global Grupo Local ADS_GROUP_TYPE_LOCAL_GROUP ADS_GROUP_TYPE_UNIVERSAL_GROUP ADS_GROUP_TYPE_SECURITY_ENABLED 0x0004 0x0008 0x8000 Grupo Local Grupo Universal Grupo de Segurana de Domnio

2.10 Operaes sobre o Active Directory

O Active Directory dispe de um conjunto de operaes que podem ser executadas sobre todos os objetos do Active Directory. Essas operaes permitem aos administradores de rede gerir os recursos disponveis na rede, como usurios, impressoras, computadores, pastas compartilhadas, bem como atribuir ou negar acesso aos mesmos. Segundo Pereira (2005, p.2) O Active Directory fornece funcionalidade de servio de diretrio, incluindo um meio de organizar, gerenciar e controlar o acesso centralmente aos recursos de rede. O Active Directory torna a topologia de rede fsica e os protocolos transparentes de forma que um usurio, em uma rede, possa obter acesso a qualquer recurso sem saber onde o recurso est ou como ele est fisicamente conectado rede.

26

Algumas operaes de segurana tambm esto atribudas ao Active Directory tais como o servio de autenticao e auditoria. Todos os recursos do Active Directory, estando devidamente cadastrado no mesmo, possibilitam que o administrador controle quem, como e quando acessou ou poder acessar o recurso.

2.10.1 Autenticao Os usurios dos recursos computacionais devem estar cadastrados no Active Directory para que possam autenticar-se (informar o nome de usurio e senha) para ter acesso aos recursos de rede. Atravs desse processo verificada a validade dos dados inseridos pelo usurio e, caso sejam vlidos, efetuada a liberao de acesso aos recursos que lhe permitido o acesso. Toda vez que o usurio tentar acessar algum recurso, o sistema verifica se o usurio possui permisso para acessar ao mesmo e, em seguida, libera ou nega o acesso. Para Hayday (2000, p. 173) o processo de autenticao pode ser dividido em duas etapas: identificar e verificar direitos. Primeiramente o servidor identifica o indivduo atravs das credenciais informadas pelo usurio no momento da autenticao na rede ou no momento do acesso ao recurso. Em seguida o servidor verifica o controle de acesso baseado nos direitos concedidos ao usurio e nas permisses vinculadas aos recursos.

2.10.2 Criao de Contas de Usurios O Active Directory fornece o gerenciamento de usurios, permitindo que o administrador cadastre, altere, exclua usurios de acordo com as necessidades apresentadas. importante que cada utilizador do domnio tenha seu nome de usurio e senha pessoal, para que sejam atribudas as permisses aos recursos de redes pertinentes ao usurio e conseqentemente tornar a rede um ambiente gerencivel e seguro. Segundo Hayday (2000, p. 72), A cada usurio que efetua logon na rede deve ser atribudo uma conta de usurio e senha de usurio, exclusivos para que voc e a rede possam identificar esse usurio. Atravs das credenciais (usurio e senha), o utilizador pode efetuar logon em computadores do domnio. Com essa identificao, o usurio tambm pode ter acesso a

27

recursos do domnio, desde que o usurio tenha as permisses de acesso ao recurso pretendido. 2.10.3 Criao de Contas de Computadores Assim como para os usurios, o Active Directory permite a identificao e o gerenciamento dos computadores pertencentes ao domnio. Para isso, o usurio deve criar uma conta para o computador antes de inserir a estao de trabalho no domnio ou o Active Directory cria automaticamente um objeto do computador no momento em que o mesmo for adicionado ao domnio. Dessa forma o administrador da rede tem a possibilidade de gerenciar os recursos oferecidos pelo mesmo, e conseqentemente, proporcionar o acesso aos recursos de forma mais segura. Para Hayday (2000, p. 73), o propsito pelos quais as contas de computadores so criadas o de fornecer um meio de se autenticar e auditorar o acesso do computador rede, e aos recursos do domnio. A conta do computador deve ter o mesmo nome do computador na rede.

2.10.4 Criao de Grupos A criao de grupos no Active Directory uma tarefa que serve pra agrupar usurios e computadores que compartilham de alguma caracterstica em comum. Dessa forma a distribuio de permisses de acesso pode ser agregada ao grupo, em vez de distribuir as permisses individualmente. Segundo Hayday (2000, p. 76), As contas de grupos so objetos do Active Directory que so colees de usurios, computadores, contatos e itens variados de outros grupos. [...] essa abordagem simplifica a administrao de rede e poupa tempo. Ao criar um grupo, deve-se definir a finalidade ao qual o grupo que est sendo criado e onde ser aplicado. Essa finalidade pode ser de segurana ou distribuio. Os grupos de segurana so utilizados para atribuir permisses de acesso aos recursos de rede, j os grupos de distribuio tm a finalidade de formar grupos que recebero uma tarefa em comum. Um exemplo da utilizao de grupos de distribuio o agrupamento de usurios que devero receber um mesmo tipo de e-mail, no caso desse servio, ele utilizado em conjunto com algum servidor de e-mail, por exemplo, o Exchange Server.

28

2.10.5 Compartilhando e Publicando Pastas O Active Directory permite realizar o compartilhamento e a publicao de pastas no Active Directory. Com o compartilhamento de pastas possvel realizar o acesso aos arquivos compartilhados de forma remota, ou seja, de qualquer computador ligado rede. O usurio tambm deve ter permisso de acesso para que possa realizar o acesso pasta. Segundo Panissa (2002, p. 46) O Windows 2000 permite que arquivos sejam compartilhados entre computadores da rede, ou publicados no Active Directory. A publicao desses recursos no Active Directory faz com que estes sejam mais facilmente encontrados, pois podem ser procurados de maneira centralizada. Com a publicao (divulgao) da pasta no Active Directory a localizao do recurso se torna mais eficiente. Isso acontece devido aps publicar a pasta no Active Directory as informaes sobre a pasta estaro centralizadas no Active Directory, fazendo com que as buscas sejam realizadas de forma mais rpida e eficiente.

2.10.6 Compartilhando e Publicando Impressoras Assim como as pastas, as impressoras tambm podem ser compartilhadas e publicadas no Active Directory. Com isso a impressora pode ser utilizada por vrios usurios na rede, de forma remota, desde que o mesmo possua a permisso para utilizar tal dispositivo. A publicao do dispositivo de impresso no Active Directory permite tambm que usurios possam localizar os recursos de forma mais simples, pois os recursos estaro armazenados de forma centralizada, tornando a busca pelo mesmo mais fcil. Hayday (2000, p. 120), define que a publicao deve ser feita quando a informao ou dispositivo til ou de interesse para a maior da comunidade de usurios. Tambm se deve publicar uma informao ou dispositivo quando se deseja torn-lo amplamente acessvel. Quando uma impressora compartilhada, ela se torna acessvel para vrios usurios. Dessa forma, a impressora que era utilizada por apenas uma estao de trabalho pode ser localizada e utilizada por uma gama de usurios, podendo assim ter uma maior utilidade na rede.

29

2.10.7 Localizar Objetos

Uma caracterstica positiva dos Active Directory que o armazenamento dos recursos e servios centralizado, e de forma lgica. Devido a esse tipo de armazenamento, os objetos podem ser localizados rapidamente e independentemente da localizao dos mesmos. Segundo Davis e Lewis (2000, p. 183-184), o Active Directory gera automaticamente um Catlogo Global com a informao dos objetos. Esse servio armazena todos os objetos e as propriedades desses respectivos objetos, tornando possvel localizao de quaisquer objetos desde que o usurio tenha acesso autorizado ao mesmo. O Active Directory disponibiliza recursos de consulta flexveis que permitem localizar objetos no diretrio de dados, com base nos atributos dos objetos cadastrados. Isso permite que sejam encontrados objetos atravs de qualquer informao cadastrada sobre o mesmo, tornando o gerenciamento de rede uma tarefa mais fcil.

2.10.7.1

Localizar Usurios

Atravs do Active Directory possvel realizar buscas por usurios na base de dados do mesmo. Para isso, o Active Directory disponibiliza um conjunto de mecanismos que permitem que sejam realizadas as buscas de forma simples e eficaz. Entre os mecanismos disponibilizados est o que permite realizar buscas utilizando-se de parmetros, o que tornam os resultados obtidos mais prximos dos desejados.

2.10.7.2

Localizar Computadores

Assim como para os usurios, o Active Directory tambm disponibiliza ferramentas para localizao de computadores do domnio atravs de filtros que permitem realizar consultas pelo prprio nome do computador ou de alguma informao que descreva o objeto, como por exemplo, a localizao do mesmo.

30

2.10.7.3

Localizar Grupos

O mesmo aplicado para os objetos referentes aos usurios e computadores aplica-se aos grupos. Atravs do Active Directory possvel localizar grupos atravs das informaes do mesmo, como por exemplo, nome e descrio.

2.11 API Java Naming and Directory Interface


A API (Application Programming Interface) JNDI (Java Naming and Directory Interface) uma interface de programao entre aplicaes e servios de diretrios, que utilizam a linguagem de programao Java. Em seu pacote so disponibilizados meios de acesso a vrios tipos de servio de nomes e diretrios, como LDAP, NIS, DNS, NDS, RMI e CORBA, atravs do mesmo cdigo Java. Isso a torna interessante pelo fato de ser necessria apenas a sua utilizao para acessar vrios tipos de servios de diretrios, isolando a aplicao dos detalhes especficos de cada protocolo. A prpria API atravs de um servio de nomes escolhe a aplicao mais apropriada para fazer o acesso ao servio especfico.

Java Naming and Directory Interface uma API especificada na tecnologia Java que permite manipular diretrio atravs de aplicaes em Java. [...] Usando JNDI, as aplicaes baseadas na tecnologia Java podem armazenar e recuperar objetos Java de qualquer tipo. A JNDI tambm fornece mtodos para executar operaes padro em diretrios, como inserir atributos aos objetos e procurar por objetos atravs de seus atributos. [...]. Permite que diferentes servios de diretrios sejam acessados atravs do mesmo cdigo da aplicao. Isto permite que aplicaes com tecnologia baseada em Java possuam a vantagem de manipular informaes em vrios tipos de servios de diretrios, tais como LDAP, de NDS, de DNS, e de NIS [...]. Utilizando a JNDI, podem-se construir aplicaes poderosas e portteis, tendo a vantagem de trabalhar com objetos em Java, tambm ter a garantia de integrao ao ambiente em que so executadas (JNDI Overview, http://java.sun.com/products/jndi/overview.html, traduo nossa).

Para a utilizao da JNDI primeiramente deve estar instalado a plataforma de desenvolvimento Java2SDK v1.3 ou superior, pois somente a partir da verso 1.3 que

31

esto disponveis as classes da JNDI. O Java2SDK v1.3 inclui em seu pacote os provedores de servio (SPs) para os protocolos LDAP, CORBA e RMI. Para o acesso aos outros provedores de servio como DNS e NIS so necessrias a atualizao do mesmo. Atravs da API possvel incluir, modificar e excluir entradas no diretrio, realizar buscas a objetos atravs de seus atributos, associarem nomes a objetos, entre outros, sem que haja o conhecimento de detalhes de implementao do protocolo a ser acessado.

Figura 4 - Arquitetura JNDI (Fonte: PIRES, 2003, slide 14, http://www.uniriotec.br/~paulo. pires/cursos/TABD1/JNDI.pdf)

Como pode ser observada na figura 4, a aplicao Java acessa a API JNDI, que por sua vez, atravs de um gerenciador de nomes, acessa o servio JNDI SPI que ter de escolher a implementao adequada para acessar o servio especfico, como, por exemplo, o LDAP, DNS, CORBA, etc. A API foi projetada para ser independente do servio que ser acessado, ou seja, com o mesmo cdigo fonte possvel acessar vrios padres de diretrios, dentre os suportados pela API. Entre eles esto o LDAP, DNS, NIS, NDS, RMI, CORBA.

32

2.11.1 Arquitetura JNDI A arquitetura da API JNDI permite que aplicaes Java tenham acesso a diferentes servios de nomes e diretrios. Basicamente se divide em duas partes: a primeira parte fornece mtodos para acessar os servios de diretrios e a outra traduz o cdigo Java, atravs do SPI (Service Provinders Interface), para atender as especificaes do protocolo e acessar o mesmo de forma transparente para o usurio. Segundo Lee (2002,

http://java.sun.com/products/jndi/tutorial/getStarted/overview/index.html, traduo nossa), a arquitetura JNDI consiste em API e SPI. As aplicaes Java utilizam a API para acessar os servios de nomes e diretrios. O SPI permite que os servios de nomes e diretrios acessem os diretrios de forma transparente para o usurio. Isso permite que atravs do mesmo cdigo Java sejam acessados diferentes servios de diretrios atravs do SPI, que identifica qual a melhor interface para acessar o servio e adapta o cdigo s caractersticas do protocolo. Dessa forma se torna possvel a realizao do acesso ao servio de diretrios atravs da aplicao.

2.11.2 Pacotes Lee (2002, http://java.sun.com/products/jndi/tutorial/getStarted/overview/index.html) divide a API JNDI em cinco pacotes, so eles: javax.naming javax.naming.directory javax.naming.event javax.naming.ldap javax.naming.spi

2.11.2.1

javax.naming

o principal pacote da API JNDI, nele esto localizadas as principais classes e interfaces para acesso ao servio de nomes. Atravs desse pacote possvel efetuar a busca, alterao, insero, remoo de objetos atravs do nome, efetuar operaes de

33

binding (associao de um nome a um objeto), criar e destruir contextos, entre outras aes. 2.11.2.2 javax.naming.directory

Este pacote uma extenso do javax.naming, nele esto disponveis as classes e interfaces que daro o acesso aos servios de diretrios. Por meio deste possvel buscar objetos atravs do nome ou atravs de seus atributos alm de realizar insero, alterao, excluso de atributos dos objetos.

2.11.2.3

javax.naming.event

Pacote que contm classes e interfaces que possuem a funo de notificar os eventos gerados a partir dos acessos aos servios de nomes e diretrios. Atravs desse pacote so obtidas informaes sobre alteraes, inseres, excluses de objetos.

2.11.2.4

javax.naming.ldap

O pacote javax.naming.ldap uma extenso do pacote javax.naming.directory que contm classes e interfaces especficas para lidar com a verso 3 do protocolo LDAP, que no esto presentes no pacote genrico, javax.naming.directory. Em grande parte das aplicaes no necessrio o uso do pacote javax.naming.ldap, pois as funes contidas no pacote javax.naming.directory so suficientes, fazendo com que o pacote

javax.naming.ldap seja utilizado apenas em aplicaes especficas.

2.11.2.5

javax.naming.spi

Nesse pacote esto presentes s classes e interfaces que sero responsveis por viabilizar a comunicao entre a aplicao e o servio de diretrios ao qual se deseja fazer o acesso, de forma dinmica, independentemente do servio a ser acessado pela aplicao. Tambm permite que sejam acessados diferentes servios de diretrios atravs da mesma aplicao, alm da associao entre os objetos dos mesmos.

3 MATERIAL E MTODOS
Para o desenvolvimento desse trabalho foram utilizados vrios recursos bibliogrficos, recursos de hardware e software, que aliados orientao permitiram a finalizao do mesmo.

3.1 Local e Perodo


Esse trabalho foi desenvolvido no segundo semestre de 2006, como requisito parcial da disciplina de Trabalho de Concluso de Curso em Sistemas de Informao I (TCC I) e Trabalho de Concluso de Curso em Sistemas de Informao II (TCC II). O local utilizado para o desenvolvimento deste foi prpria residncia.

3.2 Materiais
Os materiais utilizados para a realizao do trabalho partiram de recursos pessoais de Hardwares e Softwares, alm de materiais e ferramentas adquiridas atravs de pesquisas Internet.

3.2.1 Hardware Pentium 4, 2.4 Ghz e 512 Mb de memria RAM; Pentium 4, 2.8 Ghz e 1 Gb de memria RAM.

35

3.2.2 Softwares Microsoft Windows XP Professional; Microsoft Windows Server 2003; Microsoft Office Professional 2003; Mozila Firefox v1.0.6; JCreator Pro v3.50; JBuilder 2005; Microsoft Active Directory; Kit de desenvolvimento Java (j2sdk 1.4.1); Apache Tomcat v5.0; Microsoft SQL Server; SISGAP; Adobe Reader 7.0.1.

3.2.3 Fontes Bibliogrficas Relatrios tcnicos; Livros; Documentaes (API/Softwares); Fruns de discusso; Trabalhos Acadmicos (TCC); Dissertaes; Artigos; Sites diversos.

3.3 Metodologia
Inicialmente foi feito um estudo sobre as caractersticas da API JNDI paralelamente com os conceitos que a rodeiam, para que assim fosse adquirido um embasamento terico que proporcionasse o conhecimento necessrio para o planejamento e posteriormente desenvolvimento do trabalho. Dentre as tecnologias estudadas est o servio de diretrios

36

Active Directory, ferramenta presente no Windows Server 2003, que foi o servio de diretrio escolhido entre outros servios, para realizar o acesso atravs da API JNDI, que proporciona que aplicaes Java interajam com vrios servios de nomes, entre eles o LDAP, que o protocolo base do Active Directory. Aps esse levantamento inicial teve inicio a documentao (Reviso Bibliogrfica) dos conceitos que envolvem o trabalho. Entre os conceitos estudados est o protocolo LDAP, o Active Directory e API JNDI. Posteriormente foi iniciada a implementao do projeto, colocando em prtica os conhecimentos adquiridos na etapa de reviso bibliogrfica. Essa etapa foi caracterizada pela instalao do Windows 2003 Server seguida da instalao do Active Directory. Na seqncia foi iniciada a implementao de mtodos de acesso e manipulao de objetos do Active Directory, atravs da API JNDI. No momento seguinte foi realizada a migrao do Sistema SISGAP, para que o mesmo utilizasse a base de usurios do Active Directory como base de dados para realizao da autenticao dos usurios do sistema. Por fim, foi feita a documentao dos resultados obtidos na implementao do trabalho, juntamente com as dificuldades surgidas e as concluses alcanadas. Para um melhor entendimento da seqncia das atividades que foram desenvolvidas no trabalho, foi traado um cronograma das atividades desenvolvidas e relacionadas com perodo em que cada uma foi desenvolvida, como est sendo apresentado na Tabela 3. Tabela 3: Cronograma de Atividades
Meses Atividade Agosto Setembro Outubro Novembro

Reviso de Literatura (LDAP) Reviso de Literatura (AD) Reviso de Literatura (JNDI) Documentao da Reviso Literria Implementao Documentao da implementao Resultados e Consideraes Reviso

4 RESULTADOS E DISCUSSO
Nesse captulo sero abordados os resultados obtidos do estudo da API Java Naming and Directory Interface como forma de acesso a servios de diretrios. Para esse estudo foi utilizado o servio de diretrios Microsoft Active Directory como base de dados para a realizao de operaes de incluso, remoo, alteraes, consultas e autenticao no servio de diretrios, atravs da API JNDI. Como forma de demonstrar uma aplicao prtica de utilizao da API JNDI, foi realizada a migrao de uma aplicao JSP visando que a mesma utilizasse a base de dados do Active Directory para realizar a autenticao dos usurios do sistema, no caso o SISGAP. O SISGAP (Sistema de Gerenciamento Acadmico e Pessoal) uma aplicao JSP, que utiliza um banco de dados relacional para realizar a autenticao dos seus usurios. Foi desenvolvido no primeiro semestre de 2004, por alunos da disciplina de Desenvolvimento de Sistemas de Informao I, do CEULP/ULBRA; ser utilizado nesse trabalho como exemplo de migrao passando da base de dados relacional para um Servio de Diretrios, atravs da JNDI. Comumente, em um ambiente corporativo, cada aplicao dispe de uma base de dados particular para o armazenamento das credenciais de acesso e demais informaes dos usurios. Dessa forma, a utilizao de cada aplicao condicionada ao cadastramento de um login e senha especfica para cada usurio. Como pode ser observado na Figura 5, para cada aplicao o usurio utiliza um login especfico (jsmith, joan, joan.smith e joansmith), fazendo com que o usurio tenha a necessidade de memorizar as credenciais especficas de cada aplicao, alm de adequar suas respectivas credenciais as polticas de login e senha exclusivas da aplicao.

38

Isso acontece devido heterogeneidade das aplicaes, que no disponibilizam de meios para se integrar a diversas bases de dados. Devido a essa falta de integrao entre as aplicaes, h a necessidade de que cada aplicao possua sua base de dados particular para o armazenamento dos dados pessoais e credenciais de acesso dos usurios. Essa necessidade faz com que se gerem redundncias e inconsistncias de dados, devido duplicao de dados dos usurios e a no atualizao sncrona das informaes em todas as bases de dados, respectivamente.

Figura 5 - Usurios distintos para cada aplicao (Fonte: Baseado no modelo disponibilizado pela CENTRIFY CORPORATION, http://www.centrify.com/downloads/public/centrify_ds_directcontrol.pdf)

Com a utilizao da API JNDI h a possibilidade de se realizar a integrao das aplicaes, e assim utilizar apenas uma base dados para armazenar os dados dos usurios e de suas respectivas credenciais de acesso. Dessa forma se proporciona aos usurios a convenincia de possuir apenas uma credencial (usurio e senha) para realizar o acesso a vrias aplicaes dentro de um ambiente corporativo, pois o acesso realizado atravs do mesmo login.

39

Como pode ser observada na Figura 6, a API JNDI permite integrar sistemas heterogneos a uma base de dados nica, no caso, as aplicaes foram integradas a base de dados do Active Directory. Com a base de dados unificada, reduz-se a ocorrncia de redundncias e inconsistncias de dados entre as bases de dados. Outro fator importante de possuir uma base de dados unificada a possibilidade de realizar o gerenciamento das informaes dos usurios de forma centralizada.

Figura 6 - Usurio nico para todos os aplicativos (Fonte: Baseado no modelo disponibilizado pela CENTRIFY CORPORATION, http://www.centrify.com/downloads/public/centrify_ds_directcontrol.pdf)

Nas sees seguintes sero abordados os resultados obtidos com a utilizao da referida API. Tambm ser realizada a explanao dos possveis pontos positivos e das dificuldades, que surgiram na implementao da tecnologia JNDI, utilizada como base para o desenvolvimento desse trabalho.

4.1 Acessando um Servio de Diretrios


Inicialmente ser trabalhada a configurao da aplicao para que ela possa conectar ao servio de diretrios, no caso, o Active Directory do Windows Server. Primeiro

40

necessrio que seja estabelecida a conexo entre a aplicao e o servio de diretrios, para que em seguida possam ser efetuadas as operaes desejadas. Nessa etapa sero apresentadas as configuraes a serem realizadas para que a aplicao acesse o Active Directory. Depois de instalados o J2SDK e o servio de diretrios (Active Directory), j pode ser efetuado o acesso ao servio de diretrios utilizando a API JNDI. Para isso, devem ser configuradas as variveis de ambiente utilizando o Hashtable, que ser responsvel por mapear as variveis aos seus valores correspondentes. As variveis de ambiente a serem configuradas so: o tipo de servio a ser acessado, o endereo de acesso ao servio, o tipo de autenticao, as credenciais a serem utilizadas para a realizao das operaes desejadas (usurios e senha com as permisses necessrias para realizar as operaes desejadas), e caso seja necessrio, o protocolo de segurana a ser utilizado na autenticao. No caso do protocolo de segurana s deve ser inicializado caso se deseje fazer o uso do mesmo, sendo que no obrigatria a sua utilizao. Aps serem configuradas as variveis de ambiente e antes da execuo de qualquer operao, se deve criar um contexto inicial que ser o ponto de partida aos quais as operaes sero executadas. O contexto inicial o ponto de partida responsvel pela execuo das operaes no diretrio. Para realizar qualquer operao em um diretrio necessrio definir um ponto de partida (raiz), que ocorre atravs da instanciao do contexto inicial, que estabelece a raiz, ou topo de um diretrio, de onde partiro as operaes a serem executadas no mesmo. Segundo Pires (2003, www.uniriotec.br/~paulo.pires/cursos/TABD1/JNDI.pdf) o contexto inicial o ponto de partida (raiz) para todas as operaes, onde se pode recuperar, ligar, desligar e re-nomear objetos, e criar e destruir contextos. A instanciao de um contexto inicial realizada atravs do mtodo construtor, que recebe como parmetro as propriedades para a criao do ambiente que ser responsvel pela execuo das operaes. Existem trs mtodos construtores que podem ser utilizados para instanciao do contexto inicial, so eles: InitialContext(); o Nenhuma propriedade fornecida. criado um contexto inicial novo (nulo); InitialContext(boolean lazy);

41

o Caso o parmetro seja falso, iniciado o contexto novo (nulo); InitialContext(Hashtable environment); o Inicia o contexto com o ambiente fornecido atravs do Hashtable.

Com o contexto inicial criado deve-se inserir o cdigo que realizar as operaes desejadas. Para haver um melhor entendimento sobre a configurao e funcionamento dos parmetros e mtodos acima citados, ser apresentado um trecho de cdigo que realiza as configuraes mencionadas acima.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

public class testeJNDI{ public static void main (String[] args){ Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.SECURITY_AUTHENTICATION,"simple"); env.put(Context.SECURITY_PRINCIPAL,"Administrador@frsl"); env.put(Context.SECURITY_CREDENTIALS,"senha@dm"); env.put(Context.PROVIDER_URL,"ldap://frsl.com.br:389"); LdapContext ctx = new InitialLdapContext(env,null); /** *Cdigo fonte que executa as operaes * no servio desejado */ ctx.close(); }

14. 15. 16. }

Figura 7 - Acessando servio de diretrios

Como pode ser observado na Figura 7, na linha 3 criada uma instncia da classe Hashtable que ir armazenar os valores relacionados s variveis de ambiente que sero instanciadas. Na linha 4 atribudo constante

Context.INITIAL_CONTEXT_FACTORY o nome do servio que ser acessado pela aplicao, no caso, por se tratar de um diretrio LDAP, o valor atribudo foi com.sun.jndi.ldap.LdapCtxFactory. Em seguida, foi atribudo constante Context.SECURITY_AUTHENTICATION, o tipo de autenticao que ser utilizada

42

pela aplicao para realizar o acesso ao servio de diretrios. Existem trs modos de autenticao: none (no h autenticao); simple (autenticao simples com usurio e senha); strong (autenticao combinada com protocolo de segurana). A autenticao utilizada foi a simples, com usurio e senha. Portanto foi atribudo a varivel o valor simple (linha 5). Para acessar ao servio de diretrios Active Directory obrigatria a autenticao, ou seja, no permitida a autenticao atravs do modo none. Na seqncia, foi atribuda a constante Context.SECURITY_PRINCIPAL, que armazena o nome do usurio com as permisses necessrias para realizar as operaes, o valor Administrador@frsl que representa o usurio Administrador e o domnio ao qual ele faz parte, que o domnio frsl. Na seqncia atribuiu-se constante Context.SECURITY_CREDENTIALS, a senha referente ao usurio mencionado anteriormente, que senha@dm (linhas 6 e 7 respectivamente). Para que a aplicao seja executada, necessrio que o usurio e senha estejam corretos e que o perfil do usurio contenha as permisses necessrias para realizar as operaes desejadas. Na linha 8, foi atribudo constante Context.PROVIDER_URL o valor referente ao endereo (URL) de onde se encontra o servio de diretrios que est sendo acessado pela aplicao, seguido da porta utilizada pelo mesmo. O endereo a ser acessado ldap://frsl.com.br:389, onde frsl.com.br:389 o endereo do servio de diretrios LDAP, acompanhado da porta 389, que utilizada para o acesso. Por fim inicializado o contexto inicial, passando como parmetros as constantes instanciadas anteriormente e armazenadas no Hashtable (linha 9). Atravs dessa seqncia a conexo com o servio de diretrio concluda, com isso, j pode ser inserido na seqncia o cdigo referente s operaes que se deseja executar no servio de diretrios e depois realizada a finalizao do contexto, como observado na linha 14. Uma dificuldade no acesso ao servio de diretrio surgiu quando foi utilizado o mecanismo SASL (Simple Authentication and Security Layer) de autenticao, como o protocolo Digest-MD5 e Kerberos. Apesar de a JNDI permitir a utilizao do SASL para realizar a autenticao dos usurios nos servios de diretrios, o mesmo no pode ser utilizado, em especial com o Active Directory, pois ele possui detalhes especficos de implementao que impedem a utilizao desses mecanismos de autenticao atravs da API JNDI. Dessa forma, a autenticao foi realizada no modo simples, sem que houvesse

43

mecanismos de segurana na troca de informaes entre a aplicao e o servio de diretrios.

4.2 Adicionando Objetos no Diretrio


Aps o acesso ao servio de diretrios ser devidamente configurado, j podem ser executadas as operaes sobre os objetos do servio de diretrio, no caso, o Microsoft Active Directory. Entre as operaes que podem ser executadas no Active Directory atravs da API JNDI est a de insero de objetos na base de dados do servio de diretrio. Para isso necessrio que aps ser realizada a instanciao do contexto inicial, seja executado alguns mtodos disponibilizados pela API. Esses Mtodos iro proporcionar a insero de objetos na base de dados do Active Directory, no caso, ser inserido um objeto do tipo usurio. Iro ser inseridas na base de dados do diretrio as informaes sobre um determinado usurio, atravs da API JNDI, juntamente com a aplicao Java. Para realizao dessa operao de insero de dados de usurios na base de dados do servio de diretrio, ser utilizado o mtodo createSubcontext() que permite criar objetos dentro do diretrio, desde que sejam obedecidas as regras especficas de cada diretrio, definidas no Schema. Para criao de objetos junto ao servio de diretrios atravs do mtodo createSubcontext() necessrio que se passe como parmetros para o mtodo os dados do objeto a ser criado. Dentre os atributos obrigatrios para a criao de um objeto do tipo usurio so os atributos tipo do objeto (objectClass) que define o tipo do objeto que est sendo criado, no caso usurio (user), e o atributo referente ao nome do usurio (samAccountName), que utilizado como atributo identificador, devendo ser nico na base de dados. Nas Figuras 8 e 9, sero exibidos dois trechos de cdigos que representam o processo de adio de objetos no servio de diretrios, atravs da API JNDI.

44

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

try { LdapContext ctx = new InitialLdapContext(env,null); Attributes attr = new BasicAttributes(true); attr.put("objectClass","user"); attr.put("samAccountName","fabricirodrigo"); attr.put("cn","Fabricio Rodrigo"); attr.put("giveName","Fabricio"); attr.put("sn","Rodrigo"); attr.put("displayName","Fabrcio Rodrigo"); attr.put("description","Vendedor"); attr.put("mail","fabricio@jndi.com.br"); Context criar = ctx.createSubcontext( CN=fabriciorodrigo,CN=Users,DC=frsl,DC=com,DC=br, attrs); ctx.close(); } catch (NamingException e){ System.err.println("Erro na criao da conta: " + e); }

13. 14. 15. 16. 17.

Figura 8 - Criando usurio

Na Figura 8, depois de criado o contexto inicial na linha 2, criada uma varivel attr do tipo atributo na linha 3. Nas linhas 4 e 5 respectivamente so atribudos os atributos obrigatrios que so respectivamente o tipo do objeto a ser criado e o nome de usurio do mesmo. Entre as linhas 6 a 11 so preenchidos os demais atributos no obrigatrios para que o novo usurio possa ser adicionado ao Active Directory. Na seqncia (linha 12) efetivamente criado o usurio no diretrio atravs do mtodo createSubcontext(), passando os parmetros o diretrio onde ser criado o novo objeto, no caso CN=fabriciorodrigo,CN=Users,DC=frsl,DC=com,DC=br, e os dados do usurio a ser criado, que foram armazenados na varivel attr. Aps a execuo da rotina apresentada na figura 8 o objeto do usurio fabriciorodrigo criado, juntamente com seus respectivos atributos, dentro do grupo Users (Usurios) no domnio frsl.com.br. Caso no sejam inseridos todos os atributos referentes ao objeto criado, o servio de diretrios os mantm nulo no caso de atributos opcionais. Caso sejam atributos obrigatrios, so instanciados com valores padres.

45

1. try { 2. LdapContext ctx = new InitialLdapContext(env,null); 3. 4. 5. 6. 7. 8. 9. 10. Attributes attrs = new BasicAttributes(true); attrs.put("objectClass","group"); attrs.put("samAccountName","Vendedores"); attrs.put("cn","Vendedores"); attrs.put("description","Vendedores FRSL"); int LOCAL_GROUP = 0x0004; attrs.put("groupType",Integer.toString(LOCAL_GROUP)); Context result = ctx.createSubcontext( "CN=Vendedores,OU=adm,DC=frsl,DC=com,DC=br", attrs); ctx.close(); } catch (NamingException e) { System.err.println("Erro na criao da conta: " + e); } Figura 9 - Criando grupo

11. 12. 13. 14. 15.

Como pode ser observada na Figura 9, a insero de um objeto do tipo grupo no Active directory semelhante insero de um objeto do tipo usurio, salvo alguns detalhes especficos. O principal detalhe est na atribuio do tipo de objeto a ser criado atravs do atributo objectClass, que no caso do grupo defino do como group. Uma outra caracterstica na criao de um grupo est na definio do tipo de grupo a ser criado. Para isso aplicado ao atributo groupType o tipo de grupo a ser criado atravs de uma seqncia de instrues que determinam qual o grupo a ser criado. Na linha 9 foi inserida a seqncia 0x0004 que a seqncia referente ao tipo de grupo local. A atribuio do tipo de grupo groupType foi uma dificuldade encontrada devido o seu armazenamento no ser efetuado de forma literal, como grande parte dos atributos e sim em forma de instrues.

46

4.3 Removendo Objetos do Diretrio


Assim como podem ser inseridos novos objetos no diretrio atravs da API JNDI, ela tambm disponibiliza mtodos que permitem realizar a remoo dos mesmos. Para isso o acesso ao servio de diretrio deve estar devidamente configurado para que possa ser executado o cdigo que ir fazer a remoo do objeto desejado. A remoo do objeto efetuada atravs do mtodo destroySubcontext() que recebe como parmetro, os dados do objeto a ser removido. Para que o mtodo seja executado tambm deve ser criado um contexto inicial, que ir funcionar como um ponto de partida para a execuo das operaes. Na Figura 10 ser apresentado um trecho do cdigo que representa de forma prtica como feita a remoo de objetos do Active Directory atravs dos mtodos disponibilizados pela API JNDI.

1. try { 2. 3. LdapContext ctx = new InitialLdapContext(env,null); ctx.destroySubcontext( CN=fabriciorodrigo,OU=adm,DC=frsl,DC=com,DC=br); ctx.close(); System.out.println("Usurio removido);

4. 5.

6. } 7. catch (NamingException e) { 8. System.err.println("Erro a o remover " + e); 9. } Figura 10 - Removendo usurio

Aps a inicializao do contexto na linha 2, executado o mtodo destroySubcontext() que recebe como parmetro os dados referentes ao objeto que se pretende realizar a remoo do diretrio (linha 3). Como pode ser observado no cdigo da figura 10, foi passado como parmetro a string

CN=fabriciorodrigo,OU=adm,DC=frsl,DC=com,DC=br. Atravs da execuo dessa string como parmetro do mtodo cdigo destroySubcontext(), removido do diretrio o objeto do usurio fabriciorodrigo, pertencente unidade organizacional denominada adm, que por sua vez pertence ao controlador de domnio frsl.com.br.

47

4.4 Modificando Objetos/Atributos do Diretrio


Outra operao a ser executada atravs da API JNDI a de modificao dos dados dos atributos dos objetos. Isso acontece atravs do mtodo modifyAtributes() que permite que sejam realizadas modificaes nos objetos bem como adicionar ou remover atributos aos mesmos. Como parmetro esse mtodo recebe um objeto

ModificationItem que composto de uma tupla com o(s) atributo(s) a ser(em) modificado(s) juntamente com o tipo de modificao a ser executada. As modificaes a serem realizadas nos atributos dos objetos so especificadas atravs do parmetro que passado no mtodo, definindo atravs do mesmo, o tipo de modificao que ser realizada no objeto. Entre as operaes possveis est a de modificao, adio ou remoo do atributo, que so respectivamente representados por: DirContext.REPLACE_ATTRIBUTE; DirContext.ADD_ATTRIBUTE; DirContext.REMOVE_ATTRIBUTE. Para melhor entendimento do contedo explanado, ser apresentado na Figura 11, um trecho do cdigo que demonstra o funcionamento do mtodo que realiza a modificao dos objetos.

1. try{ 2. LdapContext ctx = new InitialLdapContext(env,null); 3. 4. ModificationItem membro[] = new ModificationItem[1]; membro[0]= new ModificationItem( DirContext.ADD_ATTRIBUTE, new BasicAttribute("member", CN=fabriciorodrigo,OU=adm,DC=frsl,DC=com,DC=br"));

5. ctx.modifyAttributes("CN=Moderador,OU=adm,DC=frsl,DC=com,DC=br", membro); 6. System.out.println("Usuario adicionado ao grupo"); 7. } 8. catch (NamingException e) { 9. System.err.println("Problema na modificao" + e); 10. } Figura 11 - Modificando objetos

48

Depois de ser criado o contexto inicial na linha 2, o vetor membro do tipo ModificationItem instanciado como nmero de atributos a serem modificados, no caso, ser realizada uma modificao (linha 3). Na linha 4, atribudo ao vetor membro o tipo de modificao a ser realizada atravs do parmetro

DirContext.ADD_ATTRIBUTE que indica que ser realizada a insero de atributos ao objeto. Devido ser uma insero de atributo tambm deve ser passado como parmetro o objeto a ser inserido, que no caso definido como um atributo do tipo member e associado ao usurio CN=fabriciorodrigo,OU=adm,DC=frsl,DC=com,DC=br. Depois de definidos os atributos a serem modificados, executado o mtodo

modifyAttributes() que tem como parmetros o objeto a ser modificado CN=Moderador,OU=adm,DC=frsl,DC=com,DC=br e a modificao a ser efetuada que foi definida no vetor membro (linha 5). Atravs da execuo desse cdigo, foi adicionado ao grupo Moderador que pertence a unidade organizacional adm do domnio frsl.com.br, o usurio fabriciorodrigo que faz parte da mesma unidade organizacional e domnio do grupo.

4.5 Buscando Objetos/Atributos do Diretrio


Uma das caractersticas mais importantes relacionadas aos diretrios o seu alto poder de realizao de buscas em sua base de dados, mesmo quando submetidos a vrias consultas simultneas. Dessa forma a busca se torna um dos recursos mais importantes quando tratamos de operaes com diretrios. Para isso a API JNDI disponibiliza diversos mtodos de busca s informaes nos diretrios, que vo desde o grau mais simples at os mais complexos. Esses mtodos permitem a realizao de buscas complexas que proporcionam resultados mais prximos dos esperados. Existem trs tipos para a realizao de buscas, so eles: Busca Simples; Busca com Filtros; Busca por Escopo.

49

4.5.1 Busca Simples Como pode ser observada atravs da prpria nomenclatura, a busca simples o tipo de busca menos complexa entre as disponibilizadas, pois no disponibiliza vrios parmetros para a filtragem dos resultados. Basicamente uma busca simples composta da raiz (base) onde ser realizada a busca, e os atributos a serem utilizados como parmetro. Caso necessrio tambm permitido que sejam especificados quais os atributos a serem retornados. Na Figura 12, ser exibido um trecho de cdigo que realiza a busca no diretrio atravs da tcnica de busca simples.

1. try { 2. LdapContext ctx = new InitialLdapContext(env,null); 3. Attributes attrs = new BasicAttributes( ("givenName", "Fabricio")); NamingEnumeration res = ctx.search("CN=Users", attrs);

4.

5. while (res.hasMore()) { 7. SearchResult sr = (SearchResult)res.next(); 8. System.out.println("" + sr.getName()); 9. printAttrs(sr.getAttributes()); 10. } 11.} 12.catch (NamingException e) { 13. System.out.println("Erro na busca: " + e); 14.} Figura 12 - Busca simples

Como pode ser observado na Figura 12, aps ser inicializado o contexto na linha 2 criado uma varivel attrs do tipo atributo. A essa varivel so atribudos os valores a serem utilizados como parmetro para a busca, que o atributo primeiro nome (givenName) com o valor igual a Fabrcio (linha 3). Na linha seguinte (linha 4) realizada a busca atravs do mtodo search() tendo como base para a busca o grupo usurios (Users) e como parmetros para a pesquisa no diretrio a varivel attrs. O resultado armazenado na varivel res. Em seguida, realizada uma rotina de repetio com o objetivo de exibir os resultados obtidos na realizao da busca. Para isso percorrida a varivel res, responsvel pelo armazenamento do resultado obtido na busca, e exibidos os resultados obtidos, atravs dos mtodos de impresso (linhas 5 a 10).

50

4.5.2 Busca com Filtros A busca com filtro se assemelha busca simples, distinguindo-se por alm de utilizar atributos como parmetros para as buscas, utilizam filtros que recebem expresses lgicas como parmetro que proporcionam a obteno de resultados mais precisos. Com isso, pode ser passada uma maior quantidade de argumentos como parmetro que associados a operadores lgicos permitem uma busca mais refinada. Na Figura 13 exibido um exemplo de cdigo que faz o uso de filtros para obter um resultado mais prximo do desejado.

1. try { 2. LdapContext ctx = new InitialLdapContext(env,null); 3. 4. 5. 6. String[] attr = {"givenName", "description"}; SearchControls ctls = new SearchControls(); ctls.setReturningAttributes(attr); String filtro = "(&(sn=leao)(mail~= @teste.com)(telephonenumber=*63))"; NamingEnumeration res = ctx.search("CN=Users", filtro, ctls); while (res.hasMore()) { SearchResult sr = (SearchResult)res.next(); System.out.println("" + sr.getName()); printAttrs(sr.getAttributes()); }

7. 8. 9. 10. 11. 12.

13. } 14. catch (NamingException e) { 15. System.out.println("Erro na busca: " + e); 16. } Figura 13 - Busca com filtros

Aps ter sido inicializado o contexto na linha 3, foi criado um vetor de String com os atributos que se deseja que sejam retornados pela consulta. Na seqncia (linhas 4 e 5) foi criada a varivel de controle ctls e inserida a String inicializada na linha anterior atravs do mtodo setReturningAttributes(). Na linha 6, foi criada uma String filtro com os parmetros a serem repassados na busca. Em seguida foi realizada a busca atravs do mtodo search() e armazenado o resultado na varivel res. Ao ser executado o mtodo search(), foi repassado como parmetro a base onde a busca ser realizada, no caso o grupo Usurios (Users). Tambm foi passado os

51

parmetros para a realizao da busca atravs de uma String composta pela expresso (&(sn=leao)(mail!@teste.com)(telephonenumber=*63)), que em outras palavras

significa dizer o objeto buscado deve conter o sobrenome (sn) igual a leao, no deve conter no atributo e-mail (mail) a expresso @teste.com e por fim deve apresentar a expresso 63 em seu nmero de telefone (telephonenumber). Caso os parmetros acima sejam alcanados, devem ser retornados os atributos especificados na varivel de controle, que nesse caso foram o primeiro nome (givenName) e a descrio (description). Entre as linhas 8 e 12 executada uma estrutura de repetio que passa por todos os resultados retornados (caso haja) pela busca, efetuando a impresso na tela dos atributos retornados acompanhados dos seus devidos valores. Tabela 4: Smbolos lgicos

Smbolo
& | ! = ~= >= <= =* * \

Descrio
Conjuno Disjuno Negao Igualdade Igualdade Aproximada Maior que Menor que Presena Wildcard (Nenhum ou vrios caracteres podem estar em sua posio) Escape

Para a criao das expresses lgicas que sero utilizadas como filtro para a efetuao das buscas, permitido utilizar os operadores lgicos apresentados na tabela 4 (acompanhados de suas devidas funes) como argumentos. Deve-se observar que na notao da expresso, o operador lgico deve aparecer antecedendo o(s) seu(s) argumento(s).

52

4.5.3 Busca com Escopo Uma outra possibilidade de filtragem na realizao de buscas nos servios de diretrios atravs da API JNDI a busca por escopo, onde permitida a especificao do escopo onde a busca ser realizada. Existem dois nveis que podem ser utilizados como parmetro para a realizao das buscas, so eles: SearchControls.OBJECT\_SCOPE; SearchControls.SUBTREE\_SCOPE. Caso seja atribudo o escopo da busca igual

SearchControls.OBJECT_SCOPE se est dizendo que a busca dever ser realizada apenas no objeto especificado, ou seja, ela no se estender a outros ns, no caso de haver ns filhos, por exemplo. Se atribudo o tipo de escopo igual

SearchControls.SUBTREE_SCOPE, est se determinando que a busca dever ser realizada no apenas no escopo especificado na busca, mas tambm em todos os seus ns descendentes. Caso haja ns filhos do escopo definido na busca o mesmo tambm ser percorrido na busca. Na seqncia, Figura 14 h um exemplo de cdigo que utiliza a busca por escopo.

1. try { 2. LdapContext ctx = new InitialLdapContext(env,null); 3. String[] attr = {"givenName", "description"}; 4. SearchControls ctls = new SearchControls(); 5. ctls.setReturningAttributes(attr); 6. ctls.setSearchScope(SearchControls.SUBTREE\_SCOPE); 7. 8. String filtro = "(&(sn=leao)(mail~=@teste.com)(telephonenumber=*63))"; 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. NamingEnumeration res = ctx.search("CN=Users", filtro, ctls); while (res.hasMore()) { SearchResult sr = (SearchResult)res.next(); System.out.println("" + sr.getName()); printAttrs(sr.getAttributes()); } } catch (NamingException e) { System.out.println("Erro na busca: " + e); } Figura 14 - Busca com escopo

53

A busca por escopo se assemelha bastante ao exemplo apresentado na Figura 13, que utiliza a busca com filtros. Isso acontece devido busca por escopo ser um aperfeioamento da busca com filtros, dessa forma ela pode ser utilizada em conjunto com a busca com filtros, tornando a busca ainda mais especfica. O trecho de cdigo apresentado na Figura 14 se diferencia pela insero de mais um atributo varivel de controle ctls atravs do mtodo

setSearchScope(SearchControls.SUBTREE\_SCOPE) (linha 6), que define o escopo onde a busca ser realizada. No caso, significa que a busca deve ser realizada no apenas no n Users como foi especificado, mas tambm nos ns descendentes a ele. Alm da busca por escopo e da busca com filtros, existem outros mtodos ligados varivel de controle, que no sero avaliados profundamente neste trabalho, mas que podem proporcionar buscas ainda mais precisas. Abaixo sero apresentados esses mtodos juntamente com suas respectivas funes, so eles: SearchControls.setCountLimit(); SearchControls.setTimeLimit(). Caso haja necessidade de limitar o nmero de objetos a serem retornados pela busca, pode ser utilizado o mtodo SearchControls.setCountLimit(), passando como parmetro o nmero mximo de respostas que se deseja que sejam retornadas. Se necessrio tambm possvel limitar o tempo de espera para a realizao da busca, caso no deseje esperar um tempo demasiado. Quando ultrapassar o tempo de espera determinado atravs do mtodo SearchControls.setTimeLimit(), a busca ser interrompida e ser retornado o resultado obtido dentro do tempo prestabelecido. Para que no haja um tempo limite para a realizao da busca, no se deve atribuir valores ao mtodo, ou ainda ser atribudo o valor 0.

4.6 Acesso ao servio de diretrios com conexo segura


Para a realizao de alguns tipos de operaes nos servios de diretrios, mais especificamente o Active Directory necessria a utilizao de uma conexo segura para que a operao seja realiza. Um dos exemplos de utilizao de conexo segura quando h o manuseamento de informaes consideradas de maior confidencialidade, como o caso

54

de senhas. Quando o servio de diretrios Active Directory acessado para a realizao de alguma operao relacionada com as credenciais de senha, o servio de diretrio s permite que a operao seja realizada caso os dados naveguem sob conexo segura. Os protocolos de segurana mais utilizados atualmente so os protocolos SSL (Secure Socket Layer) e TLS (Transport Layer Security).

4.6.1 SSL (Secure Socket Layer)

O SSL um protocolo de comunicao, desenvolvido pela Netscape Communications, na verso 3, que prope a criao de um ambiente seguro para comunicao entre servios na Internet. Com a utilizao do protocolo possvel a criao de um ambiente seguro atravs da autenticao, verificao de integridade e da criptografia dos dados entre as aplicaes envolvidas, de forma transparente ao usurio e independente de plataforma. Segundo Larguna (2000, p.2) o protocolo SSL permite a autenticao de servidores, encriptao de dados, integridade de mensagens e, como opo, a autenticao do cliente, operando nas comunicaes entre aplicativos de forma interopervel. Entre os protocolos que permitem a utilizao do SSL esto HTTP, Telnet, FTP, SMTP, entre outros. Para isso, o protocolo SSL implementa duas novas camadas sobre o protocolo TCP/IP como pode ser observado na Figura 15.

Figura 15 Arquitetura TCP/SSL

55

Como pode ser observado na Figura 15, o protocolo SSL implementa duas novas camadas ao protocolo TCP, entre as camadas de transporte (TCP) e a camada de aplicao, independente do protocolo utilizado pela aplicao (HTTP, Telnet, SMTP, FTP). O SSL trabalha na camada de transporte, interagindo com a camada de aplicao, por onde recebe as informaes a serem cifradas ou decifradas e encaminham para a camada de transporte, no caso, o TCP que se responsabiliza pelo envio e recepo dos dados cifrados. Para a implementao dessas camadas, esto disponveis os seguintes algoritmos criptogrficos: Algoritmos para troca de chaves de sesso: NULL, RSA, Diffie-Hellman RSA, Diffie-Hellman DSS, DHE_DSS, DHE_RSA, DH_anonymous, Fortezza/DMS; Algoritmos para definio de chaves de encriptao: NULL, RC2, RC4, IDEA, DES, 3DES, Fortezza; Algoritmos que implementam a funo de Hash: NULL, SHA, MD5; Tipos de Certificados: X.509 v1, X.509 v2, X.509 v3.

4.6.2 TSL (Transport Layer Security) O protocolo TSL foi desenvolvido pela IETF (Internet Engineering Task Force) nos padres abertos da W3C, na verso 1.0, e baseado no protocolo SSL. Assim como o protocolo SSL, o protocolo TSL tem como finalidade, prover a comunicao segura entre servios na Internet. Assim como o SSL, ele permite a utilizao de diversos servios, como Telnet, FTP, SMTP, DNS, SET, independentemente de plataforma. Outro fator do TSL que ele compatvel com o protocolo SSL. Segundo Coutinho e TLS Silva suporta trs (2006, modos de

http://www.gta.ufrj.br/grad/06_1/ssl/func_tls.htm)

autenticao: autenticao de ambas as partes, somente o servidor autenticado ou anonimato total. Sempre que o servidor estiver autenticado, o canal est seguro contra ataques, em que o atacante se posiciona entre o cliente e o servidor, logo sesses annimas devem ser evitadas. Cada parte autenticada deve possuir um certificado vlido, porm cabe a cada parte verificar tal validade e se ele no expirou ou se foi revogado. Atravs dos trs modos de autenticao o protocolo TLS tem como objetivo garantir a privacidade e a integridade dos dados em uma comunicao entre duas aplicaes de forma. Algumas caractersticas tcnicas entre os protocolos podem gerar uma

56

no-comunicao entre os protocolos, sendo que o TLS pode se utilizar de definies do SSLv3 para comunicar com aplicaes SSL. Outra caracterstica peculiar ao TLS que ele no suporta o algoritmo Fortezza, pois o mesmo possui sua arquitetura fechada.

4.6.3 Acesso ao Servio de Diretrios

Para que a aplicao possa ser executada utilizando uma conexo segura TLS necessrio que algumas configuraes sejam efetuadas na aplicao de modo que a mesma seja credenciada a trabalhar com o protocolo. Primeiramente deve-se obter um certificado de segurana, que pode ser emitido pela Autoridade de Certificao presente no Windows Server 2003. Para obter o certificado basta fazer o download do mesmo, digitando o endereo do controlador de domnio no Browser, como por exemplo,

http://frsl.com.br/certsrv, onde frsl.com.br a URL do controlador de domnio. Caso no haja uma Autoridade de Certificao do Windows Server, ou um servidor de Internet em execuo no controlador de domnio, deve-se obter um certificado de segurana de outra Autoridade Certificadora. Uma opo o projeto Free ICP http://www.freeicp.org, que gera certificados gratuitos de pequena durao (trs meses). Depois de criado o Certificado, ele dever ser importado atravs do Keytool (Key and Certificate Management Tool), que a ferramenta Java responsvel pelo gerenciamento dos certificados, atravs do comando:

#keytool -import -alias frsl -file c:/certnew.cer -keystore <Diretrio_Java>/jre/lib/securitycacerts

Por meio desse procedimento foi executada a ferramenta Keytool, atravs do mtodo keytool, que teve os seguintes parmetros: import: o parmetro que define que ser importado o certificado; alias: o apelido ao qual o certificado ser identificado; file: a localizao do certificado que est sendo importado: keystore: onde o certificado ser armazenado, onde <Diretrio_Java> o diretrio onde est instalado o Kit Java de Desenvolvimento (J2SDK).

57

Caso todas as configuraes estejam corretas ser exibida a mensagem Certificado adicionado keystore (Certificate was added to keystore) no final da importao do certificado. Realizadas as configuraes citadas, a aplicao Java j est devidamente apta a estabelecer conexes de segurana utilizando-se do protocolo TLS. Para exemplificar o acesso ao Active Directory atravs de uma conexo segura, ser mostrado um cdigo de acesso ao mesmo, com a utilizao do protocolo TLS (Transport Layer Security). O protocolo TLS prov a privacidade dos dados trocados entre duas aplicaes, no caso, a aplicao cliente e o servio de diretrios (Active Directory). Na Figura 16 exibido um trecho de cdigo de acesso ao servio de diretrios, onde ser alterada a senha do usurio. Para isso ser utilizado o protocolo TLS para a transmisso segura dos dados referentes senha do usurio.

1. try{ 2. LdapContext ctx = new InitialLdapContext(env,null); 3. StartTlsResponse tls = (StartTlsResponse)ctx.extendedOperation(new StartTlsRequest()); 4. tls.negotiate(); 5. ModificationItem[] mods = new ModificationItem[1]; 6. String novaSenha = "\"" senha1234 "\""; 7. byte[] byteSenha = novaSenha.getBytes("UTF-16LE"); 8. mods[0] = new ModificationItem(DirContext.REPLACE_ATTRIBUTE, new BasicAttribute("unicodePwd", byteSenha)); 9. ctx.modifyAttributes("CN=fabricio,OU=adm,DC=frsl,DC=com", mods); 10. 11. 12. 13. 14. 15. tls.close(); ctx.close(); } catch (IOException e) { System.out.println("Erro na alterao: " + e); }

Figura 16 - Acesso atravs de conexo segura

Na Figura 16, a aplicao utiliza-se do protocolo TLS para comunicar-se com o controlador de domnio. Nas linhas 3 e 4, so executados os comandos responsveis por negociar a sesso TLS, para a realizao da operao de modificao de senha. Nesse momento feita a negociao da chave a ser usada na criptografia dos dados, e

58

conseqentemente, estabelecida a relao de confiana entre a aplicao e o servio de diretrios. Na seqncia, sob o protocolo TLS inicializada uma String com a nova senha a ser inserida. Em seguida transformada em bytes Unicode UTF-16 e armazenada na varivel byteSenha (linhas 6 e 7). Unicode UTF-16 o formato que as senhas so armazenadas no Windows Server. Em seguida o atributo unicodePwd alterado pelo valor da varivel byteSenha atravs do mtodo modifyAttributes() j analisado anteriormente. Por fim, encerrada a conexo TLS.

4.7 Autenticao utilizando a base de dados do Active Directory


Com a finalidade de demonstrar uma aplicao prtica da utilizao da API JNDI no acesso aos servios de diretrios, ser apresentada a adaptao de um aplicativo para utilizar a JNDI para acessar o servio de diretrios e realizar a autenticao dos usurios utilizando-se da base de dados do mesmo, no caso ser utilizado o servio de diretrios Microsoft Active Directory. Para essa demonstrao foi utilizado o aplicativo SISGAP (Sistema de Gerenciamento Acadmico e Pessoal).

4.7.1 SISGAP

O SISGAP um sistema desenvolvido como requisito parcial da disciplina de Desenvolvimento de Sistemas de Informao do curso de Sistemas de Informao, no semestre 2004/1. A disciplina foi ministrada pelo Prof. M.Sc. Fernando Luiz de Oliveira, do CEULP (Centro Universitrio Luterano de Palmas). Esse sistema tem como finalidade fazer o gerenciamento dos materiais didticos disponibilizados pelos professores e fazer o controle de alunos e suas respectivas disciplinas, bem como, realizar o gerenciamento dos projetos de um determinado professor. Outra funcionalidade permitir o gerenciamento das suas informaes pessoais e suas respectivas agendas. Abaixo sero relacionadas s funcionalidades disponibilizadas para cada tipo de usurio, so eles:

59

Professor: consulta, incluso, alterao e excluso de materiais didticos; relacionar materiais a suas disciplinas; consulta, incluso, alterao e excluso de trabalhos para suas respectivas turmas; consultar lista de alunos matriculados ou com matricula pendente; propor projetos para a aprovao da Coordenao de Pesquisa e Extenso; consulta, incluso, alterao e excluso proposta de projetos; consulta, incluso, alterao e excluso das pessoas relacionadas ao projeto; consultar, incluir, alterar e excluir as atividades das pessoas relacionadas ao projeto; Aluno: consultar materiais didticos; consultar trabalhos; consultar disciplinas; consultar relatrios; Estagirio: consultar usurios do projeto; excluir usurios do projeto; Secretria: consultar, incluir, alterar e excluir usurios, bem como, os privilgios de cada; gerenciar projetos; consultar, incluir, alterar e excluir cursos; consultar, incluir, alterar e excluir disciplinas; consultar e alterar status do projeto (de pendente para aceito ou negado); gerar relatrios acerca dos projetos desenvolvidos; CPE (Coordenao de Pesquisa e Extenso): gerenciar projetos; Geral: acessar as informaes dos professores; gerenciar suas informaes pessoais; consultar trabalho; consultar relatrios; consultar material didtico;

60

autenticar no sistema; gerenciar agenda; o atividades pessoal e acadmica; o gerenciador de contatos; o aniversariantes e atividades do dia; consultar, incluir, alterar e excluir sites favoritos; consultar, incluir, alterar e excluir contatos;

4.7.2 Migrando a Aplicao Depois de instalado e configurado o SISGAP foi feita migrao do mesmo para que passasse a realizar a autenticao dos usurios da base de dados do Microsoft SQL Server para a base de dados do Microsoft Active Directory. Na Figura 17 apresentado o cdigo original, onde a base de dados utilizada para a realizao da autenticao o banco de dados relacional.

61

1. public class Autenticacao{ 2. private int usr_id; 3. private String usr_name; 4. private String usr_login; 5. private int usr_nivel; 6. private BancoDeDados bd; 7. public Autenticacao(){ 8. bd = new BancoDeDados(); 9. } 10. public boolean autenticarSistema(String login, String password){ 11. try { 12. boolean bs = bd.executeSelect("SELECT codUsuario, nome, login, nivel FROM tb_usuario WHERE login='"+login+"' AND senha='"+password+"'" ); 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. } if (bs && bd.hasMoreElements()){ usr_id = Integer.parseInt(bd.elementAt(1)); usr_name = bd.elementAt(2); usr_login = bd.elementAt(3); usr_nivel = Integer.parseInt(bd.elementAt(4)); return true; } return false; } catch (Exception ex) { } return false; } Figura 17 - Autenticao atravs do banco de dados

Na Figura 17 exibido o cdigo de autenticao na base de dados do Microsoft SQL Server. Como pode ser observado, o mtodo autenticarSistema() recebe o login do usurio e senha (linha 10) e realiza uma consulta ao banco de dados repassando os mesmos como parmetro (linha 12). Caso os dados de usurio e senha estejam corretos, a consulta retorna os dados referentes ao usurio. Entre os dados esto os cdigos do usurio, nome, login, nvel, e os atribui s variveis de classe. Por fim retorna que as credenciais do usurio so vlidas (linhas 14 a 18). Na migrao da aplicao para que a mesma autentique-se na base de dados do Active Directory, foi necessrio que primeiramente fosse criada uma classe para substituir a classe responsvel pela autenticao da aplicao no banco de dados. Como pode ser observado na Figura 18, inicialmente so importadas as classes que sero utilizadas pela aplicao (linhas 1 a 7), em seguida, so criadas as variveis utilizadas na aplicao (linhas 9 a 15). Por fim o contexto inicial instanciado e so inseridas as variveis de ambiente com os dados necessrios para acessar o Servio de Diretrios (17 a 29). Entre as linhas 29

62

e 33 inserido o cdigo responsvel pela realizao das operaes no Servio de Diretrios.

1. package sisgap; 2. import java.util.Hashtable; 3. import javax.naming.*; 4. import javax.naming.ldap.*; 5. import javax.naming.directory.*; 6. import java.io.*; 7. public class Authldap { 8. 9. public Hashtable env = null; 10. public LdapContext ctx = null; 11. public Control[] connCtls = null; 12. private int usr_id = 3; 13. private String usr_name; 14. private String usr_login; 15. private int usr_nivel; 16. 17. public Authldap(String ldapurl) { 18. env = new Hashtable(); 19. env.put(Context.INITIAL_CONTEXT_FACTORY," com.sun.jndi.ldap.LdapCtxFactory"); 20. env.put(Context.SECURITY_AUTHENTICATION,"simple"); 21. env.put(Context.PROVIDER_URL,ldapurl); 22. connCtls = new Control[] {new FastBindConnectionControl()}; 23. try{ 24. ctx = new InitialLdapContext(env,connCtls); 25. } 26. catch (NamingException e) { 27. System.out.println("Naming exception " + e); 28. } 29. } 30. . 31. . 32. . 33. } Figura 18 - Acessando o Servio de Diretrios

Entre as operaes implementadas est a de autenticao, retornar nome, retornar nvel. Em seguida, na Figura 19, apresentado o cdigo referente ao mtodo de autenticao do sistema.

63

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

public boolean autenticar(String usuario, String senha) { try{ usr_login = username; ctx.addToEnvironment(Context.SECURITY_PRINCIPAL,usuario); ctx.addToEnvironment(Context.SECURITY_CREDENTIALS,senha); ctx.reconnect(Ctls); return true; } catch (AuthenticationException e) { System.out.println(username + " usuario invalido "); return false; } catch (NamingException e) { System.out.println(username + " erro no contexto "); return false; } } Figura 19 - Autenticando no Servio de Diretrios

Na Figura 19 o mtodo autenticar() recebe o nome do usurio e a respectiva senha para realizar a autenticao dos dados no servio de diretrios (linha 1). Nas linhas 4 e 5 so atribudas as credenciais (usurio e senha) do usurio varivel de contexto e em seguida verificada a validade dos mesmos atravs do mtodo reconnect() (linha 6). Na autenticao atravs do servio de diretrios no foi possvel o retorno dos dados do usurio, pois o mesmo apenas verifica, mas no retorna os dados do usurio. Para sanar essa adversidade, os mtodos que retornam os dados referentes ao usurio autenticado so realizados separadamente e armazenados na classe que gerencia o controle de acesso. Como pode ser observado na Figura 20, onde exibido o mtodo responsvel por retornar o nome do usurio que est autenticando-se no sistema.

64

1. public String getUserName(String username){ 2. try { 3. SearchControls searchCtls = new SearchControls(); 4. String returnedAtts[]={"givenName"}; 5. searchCtls.setReturningAttributes(returnedAtts); 6. searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE); 7. String searchFilter = "(&(objectClass=user)(samAccountName=" + username + "))"; 8. String searchBase = "DC=frsl,DC=com,DC=br"; 9. NamingEnumeration answer = ctx.search(searchBase, searchFilter, searchCtls); 10. while (answer.hasMoreElements()) { 11. SearchResult sr = (SearchResult)answer.next(); 12. Attributes attrs = sr.getAttributes(); 13. if (attrs != null) { 14. try { 15. usr_name = (String) attrs.get("givenName").get(); 16. } 17. catch (NullPointerException e){ 18. System.out.println(); 19. } 20. } 21. } 22. } 23. catch (NamingException e) { 24. System.err.println("Problem searching directory: " + e); 25. } 26. return usr_name; 27. }

Figura 20 Buscando Usurio

Na Figura 20 realizada a busca no diretrio, atravs do mtodo getUserName(), tendo como parmetro o login do usurio utilizado na autenticao do sistema. Entre as linhas 3 e 8 so inseridas as condies para a realizao da busca e na seqncia a mesma realizada atravs do mtodo search() (linha 9). Em seguida o resultado da busca armazenado na varivel usr_name, referente ao nome do usurio. Para que a aplicao tivesse seu funcionamento normal, algumas modificaes tiveram que ocorrer na base de dados do servio de diretrios para que a mesma se adaptasse s caractersticas da aplicao. Algumas dessas adaptaes vieram atravs da implementao do cdigo e outras na adaptao da base de dados. Uma das adaptaes realizadas se refere ao nvel de acesso (Diretor, Professor, Secretrio, Coordenador de Pesquisa e Aluno) do usurio que fornecido de acordo com o valor representado atravs do campo nvel na tabela usurio no banco de dados. Como esse dado no constava na base de dados do Active Directory, foi adaptado atravs do atributo descrio do diretrio. Assim para cada usurio do sistema foi inserido o nvel de

65

acesso do mesmo atravs atributo descrio. Dessa forma, o nvel de acesso de cada usurio foi definido atravs da leitura do atributo description do Active Directory. Na Figura 21 apresentado o mtodo responsvel por realizar a busca do nvel de acesso do usurio atravs do login do mesmo.

1. public int getUserNivel(String username){ 2. try { 3. SearchControls searchCtls = new SearchControls(); 4. String returnedAtts[]={"description"}; 5. searchCtls.setReturningAttributes(returnedAtts); 6. searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE); 7. String searchFilter = "(&(objectClass=user)(samAccountName=" + username + "))"; 8. String searchBase = "DC=frsl,DC=com,DC=br"; 9. NamingEnumeration answer = ctx.search(searchBase, searchFilter, searchCtls); 10. while (answer.hasMoreElements()) { 11. SearchResult sr = (SearchResult)answer.next(); 12. Attributes attrs = sr.getAttributes(); 13. if (attrs != null) { 14. try { 15. String descr = (String) attrs.get("description").get(); 16. usr_nivel = Integer.parseInt(descr); 17. } 18. catch (NullPointerException e){ 19. System.out.println(); 20. } 21. } 22. } 23. } 24. catch (NamingException e) { 25. System.err.println("Problem searching directory: " + e); 26. } 27. return usr_nivel; 28. }

Figura 21 Buscando nvel de acesso

Observando a Figura 21 o mtodo getUserNivel() pode-se observar que entre as linhas 3 e 8 so definidos os parmetros para que a busca seja realizada. O parmetro utilizado na mesma o login do usurio, que por se tratar do Active Directory utilizado como atributo identificador. Atravs do mtodo search() realizada a busca no Servio de Diretrios, tendo como objetivo retornar o nvel de acesso do usurio identificado atravs do login. Para finalizar, o resultado armazenado na varivel usr_nivel (linha 16).

66

Outro ponto a ser adaptado est ligado ao cdigo de usurio presente na tabela usurio do banco de dados, mas que no constava entre os atributos do Active Directory. Quando o aplicativo realiza consultas a outras informaes do usurio, ele se utiliza do cdigo do mesmo como parmetro para realizar a consulta. Para contornar essa incompatibilidade foi implementado um mtodo que, ao realizar a autenticao do usurio no aplicativo, realiza a consulta ao banco de dados para obter o cdigo de usurio atravs do seu login. Dessa forma, caso o usurio necessite do seu cdigo de usurio durante a aplicao, o mesmo j estar disponvel. Na Figura 22 apresentado o cdigo responsvel por buscar o cdigo do usurio atravs de seu login.

1. public int public int getUserId(String username){ 2. try { 3. boolean bs = bd.executeSelect("SELECT codUsuario FROM tb_usuario WHERE login='"+username+"'"); 4. if (bs && bd.hasMoreElements()){ 5. usr_id = Integer.parseInt(bd.elementAt(1)); 6. return usr_id; 7. } 8. return 0; 9. } 10. catch (Exception ex) { 11. } 12. return 0; 13. }

Figura 22 Buscando cdigo do usurio

Na linha 3, da Figura 22, realizada uma busca na base de dados do Microsoft SQL Server, onde passado como parmetro o login do usurio para obter o cdigo do mesmo. A consulta realizada no banco de dados devido o Servio de Diretrios no armazenar tais informaes. O resultado da busca armazenado na varivel usr_id, como pode ser observado na linha 5. Portanto pode se concluir que atravs da utilizao da API JNDI como interface para que aplicaes desenvolvidas em Java interajam com servios de diretrios pode ser amplamente vivel. Assim cria-se a possibilidade de se ter uma base de dados unificada com uma menor probabilidade de ocorrncias de redundncia e inconsistncia de dados, permitindo que aplicaes tenham acesso a esses dados atravs da JNDI e caso haja necessidade realize o gerenciamento dos mesmos. Outro ponto importante ter uma base nica para autenticao de usurios, permitindo assim que os mesmos possam autenticar-se

67

nos sistemas atravs da utilizao de credenciais nicas, ou seja, o usurio ir necessitar de apenas um usurio e senha para acessar diversos sistemas. Com a utilizao da API JNDI h a necessidade de utilizar apenas um nome de usurio, pois os aplicativos podero se utilizar de uma base de dados unificada para autenticar os usurios. Dessa forma se proporciona ao usurio a facilidade de possuir apenas uma credencial (usurio e senha) para realizar o acesso a vrias aplicaes dentro de um ambiente corporativo. Porm, algumas dificuldades surgem na migrao da aplicao para que elas passem a utilizar o servio de diretrio como base de dados. Isso ocorre devido Esquema (Schema) do diretrio no estar adaptado aos tipos de dados existentes em todas as aplicaes. Dessa forma, deve haver uma adaptao no esquema do diretrio para que possa satisfazer as caractersticas de todas as aplicaes que o utilizaro. Outra forma de contornar tal dificuldade a de fazer alteraes na prpria aplicao visando adapt-la as caractersticas existentes no diretrio. Mesmo com as dificuldades na adaptao das aplicaes para utilizarem um nico servio de diretrios, a possibilidade de contar com uma base de dados unificada, que facilita o controle das informaes, sem que haja na base de dados a redundncia e inconsistncia de dados, torna vivel a utilizao da mesma. Dessa forma torna-se a utilizao da API JNDI bastante vivel, pois, proporciona ao usurio utilizar credenciais nicas para acessar a vrias aplicaes.

5 CONSIDERAES

5.1 Consideraes Finais


Os testes realizados com a utilizao da API JNDI como interface para aplicaes Java interagirem com servios de diretrios mostraram a eficcia da API em relao ao seu propsito, mais especificamente em relao ao servio de diretrios Active Directory que foi o servio utilizado na realizao dos testes. Mesmos apresentando algumas dificuldades especficas a API JNDI se mostrou uma alternativa capaz de permitir que aplicaes implementadas na linguagem Java realizassem diversas operaes de acesso e manipulao dos dados armazenados no servio de diretrios. Ela permite que essas operaes sejam executadas de forma transparente para a aplicao, sem que o programador necessite ter conhecimentos especficos da implementao do protocolo para realizar operaes nos mesmos. Porm, houve dificuldades com a utilizao dos mecanismos SASL de autenticao, como o Digest-MD5 e Kerberos. Esse obstculo surgiu devido o Active Directory possuir detalhes especficos de implementao que impedem que ele seja utilizado com esses mecanismos de autenticao atravs da API JNDI. Outra dificuldade observada foi com relao migrao da aplicao para que realizasse a autenticao no servio de diretrios. Algumas caractersticas tiveram de ser adaptadas para que a aplicao funcionasse corretamente. Para que a aplicao estivesse totalmente adaptada seria necessria uma reestruturao da mesma para que ela se adaptasse s caractersticas do diretrio. Dessa forma, vrias informaes deixariam de existir no banco de dados e passariam a ser geridas no servio de diretrios.

69

Por fim, pode-se concluir que a utilizao da API JNDI como interface no acesso a servios de diretrios uma alternativa vivel, pois a API disponibiliza meios eficazes e intuitivos para o acesso e manipulao dos dados nos servios de diretrios, proporcionando a possibilidade de utilizao de uma base de dados nica sem redundncia e inconsistncia dos dados. Tambm permite que o usurio obtenha apenas uma credencial (login e senha) para acessar a diversos servios e aplicativos em um ambiente corporativo. Porm a utilizao de uma base de dados nica pode requerer um trabalho intenso na modificao dos aplicativos para se adequarem s caractersticas particulares do servio de diretrio.

5.2 Proposta de Trabalhos Futuros


Dentre as propostas de trabalhos futuros existe a possibilidade de um estudo mais aprofundado sobre a utilizao da API JNDI juntamente com mecanismos SASL de autenticao (Digest-MD5 e Kerberos) no acesso ao servio de diretrios; mais especificamente o Microsoft Active Directory, pois o mesmo possui uma arquitetura fechada que bloqueia a utilizao do mesmo. Esses detalhes do mecanismo de autenticao segura no foram aprofundados nesse trabalho devido no estar incluso foco principal do mesmo, mas atravs de estudos especficos podem ser encontrados meios de utilizar os mecanismos de autenticao SASL para o acesso ao Active Directory. Com isso se poder permitir que as aplicaes Java autentiquem os usurios utilizando protocolos de segurana para a transmisso dos dados de usurios entre as aplicaes e o Active Directory, e assim proporcionar segurana na autenticao dos usurios. Outra proposta a ser trabalhada a migrao total de um aplicativo para o trabalho com servios de diretrios, visto que os diretrios possuem algumas caractersticas prprias que devem ser adaptadas para que aplicaes trabalhem com o mesmo. Essa migrao consiste em alm da aplicao poder autenticar-se no servio de diretrios, poder tambm gerenciar os usurios e os dados referentes aos mesmos atravs do aplicativo.

6 REFERNCIAS BIBLIOGRFICAS
BATTISTI, Jlio. Tutorial de Active Directory Parte 4. Disponvel em: <http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf>. Acessado em: 8 de setembro 2006.

BATTISTI, Jlio. Tutorial de Active Directory Parte 5. Disponvel em: <www.juliobattisti.com.br/artigos/windows/ActiveDirectory_p5.pdf>. Acessado em: 8 de setembro 2006.

COLTINHO, SILVA, Gustavo Lacerda, Renan Galvo. Trabalho de Redes de Computadores: TSL/SSL. Disponvel em:

<http://www.gta.ufrj.br/grad/06_1/ssl/principal.htm>. Acessado em: 16 de janeiro 2007.

DAVIS, LEWIS, Peter, Barry. Aprenda em 21 dias: Microsoft Windows 2000 Server; traduo de Edson Furmankiewicz e Joana Figueiredo. 1 ed. Rio de Janeiro: Campus, 2000. 863 p.

FILHO, Srgio Silveira. Um estudo da integrao do Microsoft Active Directory com Fontes de Dados Diversas. 2006. 57 p. Dissertao (Graduao) Universidade Federal de Pernambuco, Pernambuco. Disponvel em: <http://www.cin.ufpe.br/~sscf/index.php>. Acessado em: 12 de outubro 2006.

71

GOUVEIA, Bruno. LDAP para Iniciantes. Abril de 2005. Disponvel em: <http://www.ldap.org.br/modules/ldap/files/files///LDAP_iniciantes.pdf> Acessado em: 04 de setembro 2006.

HAYDAY, John. Segurana para Windows 2000: o guia de referncia; traduo de Andr L. Cardoso e Anderson Almeida. 1 ed. Rio de Janeiro: Campus, 2000. 646 p.

HBNER, Jomi Fred. Introduo a Java Server Pages. Dezembro de 2003. Disponvel em: <http://www.inf.furb.br/~jomi/java/pdf/jsp.pdf>. Acessado em: 12 de novembro.

ISQUIERDO, Gustavo Scalco. Integrao do Servio de Diretrios com o Servio de Nomes CORBA. p.75 (Mestrado) - Cincias da Computao, Universidade de So Paulo, So Paulo. Disponvel em <www.teses.usp.br/teses/disponiveis/45/45134/tde-28052003100121/>. Acessado em: 04 de setembro 2006.

LARGUNA, Luiz Aristides Rios. Monografia sobre SSL para o Curso de Extenso Segurana em Redes de Computadores. p.2 Cincias da Computao, Universidade Federal de Braslia, Braslia. Disponvel em

<http://www.cic.unb.br/docentes/pedro/trabs/ssl.pdf>. Acessado em: 18 de janeiro 2007.

LEE, Rosanna. The JNDI API Tutorial and Reference. Novembro de 2002. Disponvel em: <http://java.sun.com/products/jndi/tutorial/>. Acessado em: 16 de setembro 2006.

LIMA,

Gleidson.

Introduo

ao

JNDI.

Disponvel

em:

<http://www.j2eebrasil.com.br/mostrar/27>. Acessado em: 19 de setembro 2006.

LOSANO, Monique. Introduo ao Active Directory. Parte-1. Disponvel em: <http://www.microsoft.com/brasil/technet/Colunas/Monique/ActiveDirectory.mspx> Acesso em: 5 de setembro 2006.

72

MICROSOFT

CORPORATION.

Understanding

LDAP.

2000.

Disponvel

em:

<http://download.microsoft.com/download/3/d/3/3d32b0cd-581c-4574-8a2767e89c206a54/uldap.doc>. Acessado em: 10 de novembro 2006. MICROSOFT CORPORATION. About Active Directory Service Interfaces. 2000. Disponvel em: <http://msdn2.microsoft.com/en-us/library/aa772161.aspx>. Acessado em: 28 de novembro 2007.

OLIVEIRA, CARISSIME, TOSCANI. Rmulo de, Alexandre, Simo. Sistemas Operacionais: Windows 2000. Cap.10, p.183-201. Disponvel em:

<www.inf.ufrgs.br/~asc/livro/windows2k.pdf>. Acessado em: 05 de setembro 2006.

ORTIZ, Eduardo Bellincanta. Windows 2000 Server: Instalao, Configurao e Implementao. 1 ed. So Paulo: rica, 2001. 314 p.

PANISSA, Hlio. MCSE Exame 70-215: Instalando e configurando acesso a recursos. 1 ed. So Paulo: Novatec, 2002. v.1, 240 p.

PEREIRA, Nuno Alexandre. Introduo Resumida ao Active Directory (AD). Novembro 2004. Disponvel em:

<http://www.dei.isep.ipp.pt/~npereira/aulas/asi1/05/misc/introAD.pdf>. Acessado em: 9 de setembro 2006.

PEREIRA, Frederico. Srie Programao Java: Como instalar o Tomcat 5.0. 2004. Disponvel <http://di.asper.com.br/profs/daniela/Como%20instalar%20o%20tomcat.pdf>. em: 13 de novembro 2006. em: Acessado

PIRES,

Paulo.

Fundamentos

de

JNDI.

Disponvel

em:

<http://www.uniriotec.br/~paulo.pires/cursos/TABD1/JNDI.pdf>. Acessado em: 18 de setembro 2006.

73

ROCHA,

Helder.

Tutorial

JNDI.

Dezembro

de

2001.

Disponvel

em:

<www.argonavis.com.br/palestras/java/j523/index.html>. Acessado em: 18 de setembro 2006.

SANTOS, CAMARA, Anderson, Fbio. Implementando o Active Directory. 1 ed. Florianpolis: VisualBooks, 2002. 113 p.

SEREDA, Patrcia. Curso de JNDI. Disponvel em: <http://www.inf.ufpr.br/ patricia/parte1.html>. Acessado em: 2 de outubro 2006.

SUN MICROSYSTEMS. API document: Java Naming and Directory Interface. Julho de 1999. 76 p. Disponvel em:

<http://java.sun.com/j2se/1.5.0/docs/guide/jndi/spec/jndi/index.html>. Acessado em: 9 de outubro 2006.

ZUKOWSKI, DIAS, BARBIERO, DEVEGILI. Joel, Jucylene, Cheila, Augusto. Normas para Apresentao de Trabalhos Acadmicos e Relatrios Tcnicos do Centro Universitrio Luterano de Palmas. 2002. 41 p. Palmas-To. Disponvel em: <http://www.ulbrato.br/ensino/coordenadores/ver_material_curso.asp?$SID=&ano=2006& semestre=2&id_curso=43020>. Acessado em: 12 de novembro 2006.