Java Básico-apostila - Universidade Regional de Blumenau - fev/2002
UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS...
46
1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE PÓS-GRADUAÇÃO EM TECNOLOGIAS PARA O DESENVOLVIMENTO DE APLICAÇÕES WEB MODELO DE SEGURANÇA HIERÁRQUICO PARA WEB SITES FRANCISCO SPAETH BLUMENAU 2006
Transcript of UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS...
1
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE PÓS-GRADUAÇÃO EM TECNOLOGIAS PARA O DESENVOLVIMENTO
DE APLICAÇÕES WEB
MODELO DE SEGURANÇA HIERÁRQUICO PARA WEB SITES
FRANCISCO SPAETH
BLUMENAU
2006
2
FRANCISCO SPAETH
MODELO DE SEGURANÇA HIERÁRQUICO PARA WEB SITES
Monografia apresentada ao Programa de Pós-Graduação em Tecnologias para o Desenvolvimento de Aplicações WEB do Centro de Ciências Exatas e Naturais da Universidade Regional de Blumenau, como requisito parcial para a obtenção do grau de Especialista em Informática.
Prof. Ms. Francisco Adell Péricas – Orientador
BLUMENAU
2006
3
MODELO DE SEGURANÇA HIERÁRQUICO PARA WEB SITES
Por
FRANCISCO SPAETH
Monografia aprovada para obtenção do grau de especialista, pela Banca examinadora formada por:
_________________________________________________ Presidente: Prof. Francisco Adell Pericas, MSc - Orientador, FURB
_________________________________________________ Membro: Prof.
_________________________________________________ Membro: Prof.
_________________________________________________ Membro: Prof.
Blumenau, fevereiro de 2006
4
Resumo
Com o crescimento cada vez mais intenso da disposição de serviços em meio virtual,
principalmente a internet, vê-se uma necessidade de gerenciamento mais eficaz de acesso a estes
serviços. Sob este ponto de vista as plataformas de trabalho hoje já existentes implementam
alguns recursos muito úteis no quesito de verificação de acesso como é o caso do .Net e do Java.
Estas funções são muito úteis, porém com alguns limites. A criação de um modelo hierárquico de
segurança possibilita a criação de usuários herdáveis e a sobrescrita de permissões, por exemplo.
A criação de perfis e de usuários é uma questão de herança daí para frente. Os serviços que
podem ser acessados por usuários também são herdáveis podendo desta forma permitir acesso a
um serviço raiz e todos os serviços estendidos deste serão permitidos ao usuário. Também são
implementados dois tipos de análise quanto à verificação de acesso: uma centrada nos serviços e
outra nos usuários. A implementação do modelo proposto foi feita usando o PHP e metodologia
de programação orientação a objetos. Tendo um modelo de segurança como o apresentado neste
trabalho, desenvolvedores Web terão pouco trabalho quanto à verificação de acesso a serviços
por parte de usuários.
5
Abstract
With the growth each time more intense of services in electronic way, specially in the internet,
it’s necessary a method more efficient to manage the access to these services. In this point of
view, some platforms of work existents implements some resources very useful to confirm the
access permission like .Net and Java. These functions are useful, but with some limits. The
creation of a security model structured in hierarchy makes possible to inherit users and overwrite
permissions, for example. Of this point in ahead, profiles and users are inherit structures (that a
user is a inherited form another user that can be considered a profile). The services that can be
access from users are inherited too, with this feature we can give permission to a root service, and
the user can access each service that extends from the service granted. In this model are
implemented two ways to verify the access of an user to a service: one centered in the service and
another one centered in the user. The model implementation was done using PHP and object
oriented programming methodology. Using a security model like this one, presented in this
document, web developers will have little work considering permission access to a service from a
user.
6
Lista de Figuras
Figura 1: Template mestre para layout de uma página (HUSTED, 2004, p.313)....................... 14
Figura 2: Trechos do arquivo web.config do aplicativo exemplo (PLATT, 2002, p. 103)......... 16
Figura 3: Diagrama de Caso de Uso ........................................................................................... 24
Figura 4: Diagrama de Classes.................................................................................................... 26
Figura 5: Classes implementando as interfaces de acesso a dados. ............................................ 27
Figura 6: Diagrama de Atividade accessService (Usuário acessa serviço)................................. 28
Figura 7: Diagrama de Atividade isAccessibleFor (serviço é acessado por usuário) ................. 29
Figura 8: Diagrama de Seqüência para User (accessService)..................................................... 30
Figura 9: Diagrama de Seqüência para Service (isAccessibleFor) ............................................. 31
Figura 10: Exemplificação de Hierarquia de Usuários e Serviços................................................ 32
Figura 11: Código do método accessService da classe User ........................................................ 34
Figura 12: Código do método isAccessibleFor da classe Service................................................. 35
Figura 13: Exemplo do uso ........................................................................................................... 35
Figura 14: Exemplificação do uso do modelo junto a um cadastro de manutenção ..................... 36
Figura 15: Exemplo de página requisitando autenticação para acesso ao recurso solicitado. ...... 39
Figura 16: Exemplo de acesso ao menu por parte do administrador do website .......................... 40
Figura 17: Exemplo de acesso ao menu de gerenciamento por parte de um usuário comum....... 41
Figura 18: Manutenção de arquivos acessado por usuário com permissão de edição e exclusão 42
Figura 19: Manutenção de arquivos para usuário sem permissão para exclusão ou alteração ..... 43
Figura 20: Formulário para alteração do arquivo selecionado...................................................... 44
7
Sumário
1 INTRODUÇÃO...................................................................................................................................................9
1.1 PROBLEMA DE PESQUISA ...........................................................................................................................10
1.2 QUESTÃO DE PESQUISA ..............................................................................................................................10
1.3 OBJETIVOS......................................................................................................................................................10
1.3.1 Geral ..................................................................................................................................................................10
1.3.2 Específicos.........................................................................................................................................................10
1.4 JUSTIFICATIVA ..............................................................................................................................................11
1.5 ESTRUTURA DO TRABALHO ......................................................................................................................11
2 REVISÃO BIBLIOGRÁFICA.........................................................................................................................13
2.1 ESTRUTURA DE APLICAÇÕES....................................................................................................................13
2.2 SEGURANÇA PARA APLICAÇÕES..............................................................................................................15
2.2.1 .Net ....................................................................................................................................................................15
2.2.2 Java ....................................................................................................................................................................17
2.2.3 PHP....................................................................................................................................................................19
2.3 ARMAZENAMENTO DE DADOS..................................................................................................................20
2.3.1 Base de Dados ...................................................................................................................................................20
2.3.2 XML ..................................................................................................................................................................21
2.4 QUALIDADE DE SOFTWARE .......................................................................................................................22
3 DESENVOLVIMENTO ...................................................................................................................................24
3.1 REQUISITOS DO SISTEMA ...........................................................................................................................24
3.2 MODELO DE SEGURANÇA PROPOSTO .....................................................................................................24
3.3 TECNOLOGIAS UTILIZADAS.......................................................................................................................33
3.3.1 Armazenamento de Dados .................................................................................................................................33
3.3.2 Linguagens de Programação..............................................................................................................................33
3.4 IMPLEMENTAÇÃO DO MODELO PROPOSTO...........................................................................................34
3.4.1 Integração com Aplicações já Desenvolvidas....................................................................................................35
8
3.5 TESTES E VALIDAÇÕES ...............................................................................................................................37
3.5.1 Implementações reais com o modelo proposto ..................................................................................................38
4 CONCLUSÃO...................................................................................................................................................45
9
1 Introdução
Como vemos todos os dias, cada vez mais os consumidores estão procurando
comodidade. As empresas para atingirem este consumidor em potencial dispõem serviços de
forma a atingir a expectativa deste consumidor, um dos meios pelos quais ela atinge o
consumidor é fazendo uso da internet. Dispondo em seu website um meio para comercio
eletrônico.
Ao ver que serviços dispostos no website facilitavam muito a interação com a
empresa, foram desenvolvidos também aplicativos para gerência da mesma, também dispostos no
website, originando então uma extranet que poderia se acessada pelos colaboradores da empresa
para gerenciamento da mesma, bem como pelos seus clientes e fornecedores para compras e
reabastecimento de matéria prima.
Sabemos que o conteúdo visualizado por um representante, cliente e um funcionário
precisam ser diferentes, definidas de acordo com a política de acesso a informação estipulados
pela empresa. Para tanto existem os sistemas de seguranças em websites, que atua na
autenticação do usuário e na autorização de acesso a informações.
O propósito do presente trabalho é apresentar a especificação e a implementação de
um modelo de segurança hierárquico para verificação de permissões de acesso a serviços e
recursos em aplicações, mais especificamente em aplicações web. Isto envolve a criação de um
método para facilitar a verificação de autorizações e negações concedidas entre usuários e
serviços extensíveis. Desta forma espera-se reduzir o custo de gerenciamento de permissões de
grandes aplicações e facilitar o entendimento de permissões concedidas e negadas por parte do
administrador.
10
1.1 Problema de Pesquisa
Tendo que hoje a segurança quanto à verificação de acesso a serviços e recursos está
cada vez mais importante e mais específica, este trabalho tem como objetivos a pesquisa e o
desenvolvimento de um modelo hierárquico para verificação de permissão de acesso.
1.2 Questão de Pesquisa
As questões que dão rumo a este trabalho são:
• Que modelos de verificação de acesso são implementados nas plataformas de
desenvolvimento comuns atualmente como o .Net, o Java e o PHP?
• Existem formas de facilitar a verificação de acesso a recursos e serviços?
1.3 Objetivos
A seguir enunciam-se os objetivos geral e específico do presente trabalho.
1.3.1 Geral
O objetivo deste projeto é dispor um modelo de segurança e a sua implementação,
baseado em hierarquia, para controle de acesso a recursos a fim de facilitar o gerenciamento de
segurança de aplicações de grande porte voltadas à internet.
1.3.2 Específicos
Os objetivos específicos do trabalho são:
• Criar um modelo lógico flexível para armazenamento das políticas de acesso de
cada aplicação;
• Avaliar formas de armazenamento (XML e Banco de Dados);
• Desenvolver interfaces e classes básicas para o uso do modelo proposto;
11
• Dispor meios para que possam ser implementados outros meios de recuperação de
dados afim de não atrelar especificamente o projeto a um banco de dados;
• Estipular a melhor maneira de incorporar este modelo a projetos já desenvolvidos.
1.4 Justificativa
Um sistema de gerenciamento de conteúdo pode ser utilizado sobre o próprio serviço
de internet mediante o acesso desde uma extranet de uma empresa. Estas permissões de acesso
são verificadas a partir de uma engenharia de segurança que pode estar validando o usuário que
está acessando ou ainda os perfis em que o usuário está enquadrado. O comum para estas
engenharias é impor um modelo dispondo serviços (áreas de gerenciamento), usuários (pessoas
autorizadas a acessar certos serviços) e perfis (grupos de serviços que podem estar atrelados a
pessoas). Além disso, as permissões de um com o outro podem ser de permissão ou negação.
Sem um mecanismo de segurança correspondendo ao menos às características acima,
fica inviável o controle de um site Web relativamente grande pelo trabalho criado no
gerenciamento de permissões/usuários.
Agora, mais do que nunca, precisa-se flexibilidade quanto à verificação de acesso a
serviços disponibilizados. A maioria dos serviços tem duas faces: visualização e manutenção. A
visualização exibe os dados para o cliente web e a manutenção é o que envolve a manipulação de
dados. Nem todos que podem ver os dados, podem alterá-los. Desta forma cresce o número de
associações entre serviços, usuários e perfis.
1.5 Estrutura do Trabalho
Para atingir o objetivo proposto, o trabalho divide-se em duas partes: a revisão
bibliográfica e o desenvolvimento.
12
Na revisão bibliográfica dá-se foco as tecnologias que já possuem uma engenharia de
segurança formalizada como o Java e a plataforma .Net. Também fundamentamos formas de
estruturar um website com a finalidade de apresentarmos no desenvolvimento do modelo formas
a integrar as funcionalidades desenvolvidas as aplicações existentes. Outro ponto tratado na
revisão bibliográfica é o meio de armazenamento que pode ser utilizado junto à engenharia
desenvolvida como é o caso do banco de dados e XML, e sobre a qualidade de software quanto à
confiabilidade de sistemas computacionais atrelado a requisitos do sistema.
No capítulo de Desenvolvimento são apresentados os requisitos do sistema,
formulado o seu modelo, definidas as tecnologias a serem usadas a fim de desenvolver a parte
prática e apresentada a forma de integrar o modelo desenvolvido a aplicações já operando, de
forma que sejam feitas alterações pequenas, não afetando assim a engenharia do software em si.
13
2 Revisão Bibliográfica
2.1 Estrutura de Aplicações
Conforme Wankyu (2001, p. 178), um dos meios para facilitar o desenvolvimento de
aplicativos maiores é através do uso da modularização, um processo para se pensar nas tarefas
que precisam ser desempenhadas pela aplicação e subdividi-las em várias outras menores. A
explicação dele para tal ação é “É mais fácil de testar se só vai haver uma tarefa desempenhada
em uma parte específica do programa”.
Ainda conforme Wankyu (2001, p. 178):
[...] Se um módulo desempenha uma tarefa em específica, então você pode chama-lo toda vez que precisar desempenhar aquela tarefa. Você pode imaginar esses módulos como pequenas caixas pretas, onde você coloca e retira dados e, contanto que eles estejam corretos, você não precisa se preocupar com o que acontece do lado de dentro. Em PHP (e em qualquer outra linguagem), o nome dado a um “módulo” de código como este é função.
Este processo de subdividir a aplicação em módulos (partes menores) vale tanto para
a lógica da aplicação (camada de controle e modelo) quanto para a parte de visualização (layout
propriamente dito) como explana Husted (2004, p. 310):
Uma abordagem para separar o layout do conteúdo é o uso de inclusões JSP dinâmicas. A especificação JSP fornece inclusões estáticas e dinâmicas. A ação JSP padrão para inclusão dinâmica é <jsp:include>.
Fazemos uso de inclusões dinâmicas para dividir a página do servidor em vários fragmentos, cada um com seu próprio serviço a fazer. Um template de segundo plano pode definir o formato default e o layout e os fragmentos da página podem ser incluídos durante a execução para fornecer o conteúdo. Uma inclusão dinâmica envolve a saída da página incluída na página original. Age como um interruptor que move o processamento para um fragmento de página e então de volta para quem chama. [...]
Desta forma pode-se concluir que um meio interessante para fazer um layout básico
de uma página que tenha algumas áreas comuns, como menu, cabeçalho, rodapé e conteúdo, seria
criar um arquivo de menu, outro de cabeçalho, outro rodapé e um quarto que seria responsável
pela montagem da página, que nada mais faz do que executar o include do cabeçalho, do menu,
14
da página-conteúdo requisitada e do cabeçalho para formar a resposta da requisição. A página-
conteúdo que se refere anteriormente é o conteúdo a ser disposto na página conforme a
requisição, análoga à página original citado por Husted (2004).
Figura 1: Template mestre para layout de uma página (HUSTED, 2004, p.313)
Pode-se concluir também que a página original (página-conteúdo) é uma das páginas
que poderá efetuar as ações de acordo com o requisitado pelo usuário no caso de manutenções
cadastrais, alterações de dados, navegação, entre outros. É normal então que neste ponto ocorram
verificações de permissões para definir se o usuário pode ou não executar determinada tarefa ou
então acessar um recurso específico. Para ilustrar esta conclusão cita-se um trecho de Platt (2002,
p. 127):
O código da página .aspx pode fazer sua própria autorização, por meio do objeto intrínseco denominado User. Esse objeto contém um método chamado IsInRole, o qual informa se o usuário é membro do grupo administrativo que examinamos anteriormente.
Como se pode observar deixa-se meios para que ocorra a verificação na própria
lógica (lógica da página-conteúdo). Nesta citação, Platt menciona o termo autorização que é
fundamentado no item 2.2.1 do presente trabalho.
layout.jsp
header.jsp
details.jsp
footer.jsp
Detalhes do Item
Commodore 1541 Capacidade 180K Custo: $200 Alinhado?: Algumas vezes
[Main] [Logoff]
15
2.2 Segurança para Aplicações
Platt define que a segurança comum para várias plataformas é a de dois tempos:
autenticação e autorização.
Platt (2002, p. 111) define autenticação como:
[...] Autenticar um usuário geralmente toma a forma de examinar algum tipo de credencial apresentada pelo usuário, algumas vezes combinada diretamente entre duas partes, como um PIN ou uma senha; algumas vezes emitida por um terceiro em que ambos confiam, tal como uma licença de motorista ou um passaporte. Se as credenciais são satisfatórias para o servidor, este sabe quem o usuário é e pode usar sua lógica interna para determinar que ações o usuário pode realizar. Um usuário que não é autenticado é chamado de usuário anônimo. Isso não significa necessariamente que ele não possa ter acesso a nada do site Web, mas significa que ele pode ter acesso somente aos recursos que os projetistas deixaram disponíveis para os usuários anônimos – talvez verificar a programação de uma linha aérea, mas sem resgatar algum prêmio.
Pode-se verificar por meio do citado acima que autenticação nada mais é do que a
engenharia criada em um sistema para que ele confira o usuário e as senhas informadas.
Quanto à autorização, conforme Platt (2002, p. 121):
Uma vez concluído o processo de autenticação, nós sabemos quem o usuário é ou se ele é anônimo. Agora precisamos decidir se o usuário pode ver a página que ele está solicitando. Isso se chama autorização.
Agora que foram definidos os termos para tratar de segurança propriamente dito, será
analisada a plataforma .Net e Java, descrevendo uma alternativa para executar uma função
semelhante usando o PHP.
2.2.1 .Net
Como expõe Platt (2002, p. 113), existem quatro modos de autenticação no ASP.Net:
nenhum, pelo Windows (usada autenticação padrão do Windows no Internet Information Server),
por Forms (neste caso o ASP.Net verifica nos cabeçalhos HTTP por um cookie de autenticação,
ou, se não houver, o ASP.Net redirecionará para a página de autenticação configurada) e por
Passport (mesma idéia do Forms exceto que a credencial, ou cookie emitido, é fornecido pelo
16
serviço Passport da Microsoft). Desta forma, a autenticação também é auxiliada pela própria
plataforma.
Quanto à autorização, as aplicações .Net possuem mecanismos extremamente simples
para armazenar estas informações, conforme Platt (2002, p. 122) descreve:
O ASP.NET contém um bom suporte para controlar o acesso a páginas ASPX. Pode-se limitar administrativamente o acesso das páginas por meio de entradas nos arquivos web.config do aplicativo [...]
O arquivo web.config é o arquivo de configuração da aplicação que, conforme Platt
(2002, p. 102):
[...] Cada aplicativo armazena suas informações de gerenciamento da configuração ASP.Net em um arquivo chamado web.config, o qual é armazenado no diretório do próprio aplicativo. Cada arquivo conte, informações sobre a configuração expressa em um vocabulário XML particular.
Um bom exemplo do que se pode fazer usando o web.config está apresentado na
Figura 2.
<?xml version=”1.0” encoding=”utf-8”?> <configuration> <system.web> <!--DYNAMIC DEBUG COMPILATION Set compilation debug=”true” to enable ASPX debugging. Otherwise, setting this value to false will improve Runtime performance of this application. --> <compilation defaultLanguage=”vb” debug=”true”/> <!—CUSTOM ERROR MESSAGE Set customErrors mode=”true” or “RemoteOnly” to enable custom error messages, “Off” to disable. Add <error> tags for each of the errors you want to handle. --> <customErrors mode=”RemoteOnly” /> </system.web> </configuration>
Figura 2: Trechos do arquivo web.config do aplicativo exemplo (PLATT, 2002, p. 103)
Pode-se também trabalhar com diversas configurações em uma aplicação para
diferentes diretórios, usando um web.config para cada diretório específico, como explana Platt
(2002, p. 103):
17
Os arquivo web.config também podem residir em vários subdiretórios de um aplicativo. Cada arquivo web.config controla a operação de páginas contidas em seu diretório e todos os subdiretórios, a menos que haja outro arquivo no subdiretório.
Tomando como base esta citação, pode-se concluir que diversas diretivas de
configuração da aplicação podem estar “espalhadas” nos diversos diretórios da aplicação. Para
segurança, o ideal seria estar tudo centrado para uma melhor gerência, mas vale lembrar que
usando o .Net pode-se centrar as configurações de segurança mesmo possibilitando a
fragmentação das mesmas.
Como já fora citado anteriormente, pode-se definir as configurações de autenticação e
autorização nos arquivos web.config da aplicação como demonstra Platt (2002, p. 122) em um de
seus exemplos:
<authorization> <allow users=”Simba” roles=”Doctors” /> <deny users=”*”> </authorization>
A sessão <authorization> contém elementos <allow> (permitir) e <deny> (recusar)
que permitem ou não os usuários e membros dos grupos de usuários especificados acessar
páginas dos diretórios nos quais os arquivos web.config se aplicam.
Neste exemplo fica claro o trabalho do ASP.Net usando autorizações. Deve-se dar
especial atenção sobre os dois tipos de elementos existentes dentro da tag authorization, o allow
e deny, que são equivalentes ao grant e revoke em um sistema gerenciador de base de dados.
2.2.2 Java
Para introduzir o conceito imposto pelo módulo de segurança, observa-se o que diz
Kurniawan (2002, p. 226):
O conceito de principal é simples. Você pode pensar em principals como usuários. Basicamente, um principal é uma entidade. Ele pode ser um indivíduo ou outro tipo de entidade. “Principal” e “usuário” são intercambiáveis usados para referenciar uma identidade.
18
Uma função é um grupo abstrato de usuários. Ela se refere mais a uma posição do que um indivíduo. Você pode pensar em uma função como um grupo. Como tal um usuário pode ocupar uma ou mais funções.
O conceito introduzido pelo sistema de segurança usada pelo Tomcat (módulo que
pode incorporar o Java ao projeto Apache para servir aplicações Java) é simples. Este sistema é
centrado em usuários (entidades), cada qual possuindo acesso a várias funções que podem ser
consideradas ações para que se possa criar correlação entre o glossário de Kurniawan e deste
trabalho.
Estas informações de segurança podem ser armazenadas em um arquivo XML com
um formato parecido com o exemplo exposto por Kurniawan (2002, p. 337):
<tomcat-users> <user name=“Joe” password=“pwd” roles=“marketingManager”/> <user name=“Peter” password=“0192” roles=“HRManager”/> <user name=“MrDirector” password=“humblepine” roles=“marketingManager,HRManager”/> </tomcat-users>
Além da possibilidade de criar regras, pode-se definir permissões para recursos
usando o que se chama de Security-Constraint (regras de segurança), que pode restringir acesso a
recursos sem que seja escrita uma linha de código. Para exemplificar o uso de regras de
segurança, seja o exemplo criado por Kurniawan (2002, p. 338):
[...] <security-constraint> <web-resource-collection> <web-resource-name> Restricted Area </web-resource-name> <url-pattern>/servlet/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>manager</role-name> </auth-constraint> </security-constraint> [...]
No exemplo cria-se uma regra (security-constraint), onde são inseridos os recursos
gerenciados (web-resource-collection). Estes recursos gerenciados recebem um nome (no
19
exemplo o nome dado foi “Restricted Área” pelo valor da tag web-resource-name). Depois são
informados os padrões de URLs que serão verificadas por esta permissão (url-pattern), e esta
regra deve atuar sobre determinadas funções (auth-constraint).
2.2.3 PHP
Analisada a documentação do PHP constata-se que não existe nenhum conjunto de
funções capazes de fornecer segurança baseada em regras como é o caso do Java ou ainda do
.Net. Fica então como uma possível solução o uso do htaccess do Apache conforme a idéia
exposta por Marcelo (2003, p. 53).
A utilização do htaccess fica restrita às condições impostas pela configuração do
Apache, onde se pode integrar a autenticação junto a uma lista de usuário/senha conforme
dispões Marcelo (2003).
Algumas chaves de configuração podem ser usadas na configuração de acesso a um
determinado recurso usando o apache. A chave AuthName configura a mensagem que aparecerá
ao usuário ao tentar acessar o recurso afim de informá-lo que área está tentando acessar.
AuthType define a forma como deve ser feito o acesso. AuthUserFile trata do arquivo de usuários
e senhas. Require user define quais os usuários (cadastrados no AuthUserFile) podem acessar
aquele recurso.
Conforme Marcelo (2003, p. 61) existe ainda a possibilidade de criar autorização por
grupo. Às vezes, em sites pagos, é interessante criar um arquivo com a listagem dos usuários.
Para isto basta alterar o nosso htaccess com os seguintes parâmetros:
AuthName “Diretório seguro BufferOverflow” AuthTyoe Basic AuthUserFile /home/bufferoverflow/public_html/.senha AuthGroupFile /home/bufferoverflow/public_html/.grupo Require group usuarios
20
Os parâmetros AuthGroup e o Require group é que habilitam os grupo de usuário.
Para criarmos o arquivo de grupos, utilize um editor de texto como o VI e crie o arquivo .grupo,
conforme a sintaxe adiante:
Usuários: amarcelo salbrum
A criação desta estrutura acaba possibilitando a criação de um meio seguro para
executar uma aplicação Web, uma vez que o apache controla acesso aos recursos.
Esta solução não tem o mesmo nível das soluções impostas pelo .Net ou Java, uma
vez que é a segurança fornecida pelo servidor Web. Uma analogia às outras plataformas (.Net e
Java) seria o mesmo que dizer que a segurança de uma aplicação .Net seria fornecida pelo
servidor Web (geralmente Internet Information Server da Microsoft) o que é perfeitamente
possível.
2.3 Armazenamento de Dados
2.3.1 Base de Dados
De acordo com Deitel (2003, p. 774), um banco de dados é uma coleção integrada de
dados. Existem várias estratégias diferentes para organizar dados em um banco de dado, para
facilitar o acesso e a manipulação dos dados.
Ainda conforme Deitel (2003), os bancos de dados mais populares são relacionais e
quase em sua totalidade usam SQL para executar consultas e manipulação de estruturas e dados.
De acordo com O’Brien (2004, p.119), um banco de dados possibilita que diferentes
programas aplicativos do usuário acessem a mesma base de dados.
A visão de O’Brien (2004) permite concluir que o banco de dados se torna muito útil
por ser uma camada a mais, sem nenhuma relação direta com as regras de aplicação, servindo
como repositório de dados onde eles são armazenados e recuperados.
21
Para abstrair o usuário da biblioteca de funções específicas de cada banco existem
desenvolvedores que criam interfaces de acesso a banco de dados, permitindo desta maneira
utilização de um conjunto comum de funções para operar bancos de dados distintos, conforme
Deitel (2003, p. 774):
A Database Interface (DBI) de Perl oferece meios de acessar bancos de dados relacionais a partir de programas Perl. Existem muitas implementações diferentes de banco de dados relacionais (p. ex., MySQL, Microsoft Access, Oracle, etc.). Um programa de software – chamado de driver – ajuda os programas a acessar o banco de dados. Cada implementação de banco de dados exige seu próprio driver e cada driver pode ter uma sintaxe diferente para seu uso em um programa. Para facilitar o uso de todos este banco de dados diferentes, criou-se uma interface para oferecer acesso uniforme a todos os bancos de dados. Esta interface é conhecida como DBI.
Assim como em Perl , há DBIs para outras linguagens. Para PHP também pode-se
encontrar meios de criar uma DBI própria, como trata Hughes (2001) em seu livro.
2.3.2 XML
Como o banco de dados, XML também é usado para armazenar dados, conforme
Deitel (2003, p. 724) expõe:
O XML é uma tecnologia aberta, portável, amplamente suportada (isto é, tecnologia não-proprietária) para descrever dados. O XML está se tornando o padrão para armazenar dados intercambiados entre aplicativos. Usando XML os autores de documentos podem descrever qualquer tipo de dados, incluindo fórmulas matemáticas, instruções e configurações de software, música, receitas e relatórios financeiros. Os documentos XML podem ser lidos por seres humanos e máquinas.
Levando em conta a citação acima, há uma vantagem quanto ao XML sobre os
bancos de dados na configuração de aplicações. Em um banco de dados relacional o que é preciso
para alterar um parâmetro de configuração é abrir um cliente que acesse o banco de dados
executar alguns comandos SQL e então os parâmetros estarão alterados. Já em um arquivo XML
bem formado, usuários que entendam um pouco do domínio da aplicação conseguirão ler o
arquivo e alterar as configurações de maneira simples, sem precisar executar um cliente que
permita a entrada de comandos SQL.
22
2.4 Qualidade de Software
A definição de qualidade de acordo com Weinberg (1994, p. 141) é: “Qualidade é
valor para alguma pessoa.”. Outra sentença relevante que exprime de forma simples como criar
com qualidade é: “A verdadeira melhoria da qualidade sempre se inicia com o saber do que os
seus clientes querem”.
As sentenças expostas estão relacionadas ao desenvolvimento de qualquer produto,
inclusive software. De acordo com Weinberg: “se você não sabe o que seus clientes querem não
estará pronto para garantir que seus passos de melhoria de qualidade sejam passos de melhoria de
qualidade”.
Pode-se desta forma deduzir que a forma mais simples de tratar qualidade em
desenvolvimento de software é definir pontos a serem atingidos no desenvolvimento, servindo
como objetivos ou uma espécie de linha guia para que os requisitos do cliente sejam sanados
atingindo o desenvolvimento do software desejado pelo cliente, desta forma obtendo qualidade.
Quando se trata da segurança de aplicativos, principalmente quanto a acesso, está-se
falando de confiabilidade, que de acordo com Gustafson (2003, p. 99) é: “Confiabilidade é a
probabilidade de o software não falhar em um período de tempo específico”.
De acordo com Musa (1990, apud Peters 2001, p.499): “A confiabilidade é
provavelmente a característica mais importante do conceito de qualidade de software. Ela se
preocupa com a qualidade com que o software é capaz de atender as necessidades do cliente”.
Desta forma pode-se claramente definir que confiabilidade de software é
simplesmente efetuar as funcionalidades de acordo com os requisitados do cliente.
De acordo com Coward (1997, apud Peters 2001, p. 377), “O objetivo principal do
teste de software é tornar o software confiável”. Desta forma, para se atingir qualidade de
23
software precisa-se aplicar alguns testes sobre o software desenvolvido. Um meio de efetuar as
verificações de funcionalidade de um software é por meio de uma checklist que, de acordo com
Gustafson (2003, 0. 99), é uma lista de itens que devem ser verificados durante a revisão.
Também destaca a vantagem do uso de uma checklist uma vez que a atenção do revisor é focada
em problemas potenciais.
24
3 Desenvolvimento
3.1 Requisitos do Sistema
De acordo com a definição dos objetivos o modelo deve verificar permissões de
acesso a recursos, que podem envolver funções específicas, serviços, áreas visíveis no site,
arquivos dentre outros. Basicamente ele fará a busca em uma árvore de forma recursiva a fim de
estabelecer se o usuário autenticado pode ou não acessar estes recursos.
Este modelo também se apresenta flexível o suficiente a ponto de se poder
implementar acesso a dados de outras fontes (banco de dados).
3.2 Modelo de Segurança Proposto
A seguir apresenta-se a modelagem UML usando os diagramas de caso de uso, de
classes, de atividade e de seqüência para o resultado proposto.
Figura 3: Diagrama de Caso de Uso
O diagrama da Figura 3 mostra como o script atuará a fim de verificar a autorização
de acesso a serviços e recursos que sejam convenientes à verificação em tempo de execução.
Define-se que um serviço pode ser um recurso a ser solicitado (como é o caso de
verificar se o usuário pode acessar determinada página) ou uma ação a ser executada (como por
exemplo, em um cadastro onde o usuário deseja remover um registro).
25
Desta forma, a verificação ocorre de duas formas:
1. verificando se o usuário tem acesso a determinado serviço (centrado no usuário);
2. verificando se o serviço pode ser acessado por determinado usuário (centrado no
serviço).
O objetivo de existir duas formas de verificação é que a aplicação pode analisar as
permissões de dois modos como citadas acima, uma centrada no usuário e outra no serviço.
Análise centrada no usuário tem por finalidade verificar se existe alguma permissão
definida entre o serviço requisitado e o usuário em questão. Se não houver é verificado o serviço
ascendente ao solicitado até que se chegue a raiz. Ao chegar na raiz é selecionado o usuário
ascendente e verificado os serviços até a raiz para verificar se existe alguma definição de acesso.
Este processo é feito até achar alguma associação ou fim das possibilidades.
Em contrapartida a análise centrada no serviço faz o contrário: ele verifica primeiro
uma associação do usuário em questão com o serviço requisitado se não houver é feito a análise
de associações de usuários ascendentes ao serviço requisitado, ao chegar a raiz dos usuários
ascendentes é tomado o serviço ascendente e feito o teste com os usuários ascendentes ao em
questão até o término das possibilidades ou encontrar uma associação.
O uso de dois métodos tem a intenção de flexibilizar a análise em aplicações
diferentes, podendo-se dar foco ao objeto desejado. Os métodos disponíveis são: isAccessibleFor
da classe Service e accessService da classe User.
Definido o objetivo e a funcionalidade do modelo pode-se definir o digrama de
classes.
Existirão no mínimo 3 classes (Usuário, Serviço e AssociaçãoUsuárioServiço). Estas
três classes farão a interface de atividade com o script.
26
Sendo um dos objetivos do trabalho definir um modelo que seja flexível a ponto de
trabalhar com bancos de dados relacionais tanto quanto XML ou mesmo arquivos textos, a
solução encontrada é a de criar interfaces com pequenos métodos, os quais fornecem dados
(registros) para as classes que os usam de acordo com a necessidade das mesmas. Então, para
cada uma das três classes primárias, foi definida sua interface de fonte de dados (DataSource).
Figura 4: Diagrama de Classes
As interfaces de acesso a dados foram estipuladas para que não precisasse criar uma
DBI (Data Base Interface) para acessar dados de fontes diferentes da implementada para teste
(MySQL), desta forma fica simples implementar para outras fontes de dados.
Depois de implementadas as interfaces, o que se precisa fazer é passar estas interfaces
implementadas como parâmetro para os métodos nas três classes bases (User, Service e
UserServiceAtt), para assim fazer o uso destas interfaces implementadas e não precisar de
nenhuma fonte extra de dados.
27
Para os testes efetuados com a aplicação foram implementadas as interfaces em
classes de acesso a dados usando o MySQL como fonte de dados, conforme mostra o modelo
abaixo.
Figura 5: Classes implementando as interfaces de acesso a dados.
A estrutura formulada foi basicamente uma classe de conexão com o MySQL para
armazenar a conexão efetuada com um método getConnection seguindo o padrão singleTone do
GoF.
As classes que implementam os métodos das interfaces definidas pelo projeto fazem,
basicamente, seleções sobre as tabelas na base de dados do MySQL.
Os dois principais métodos, como dispostos no diagrama de casos de uso (Figura 3)
são accessService (usuário acessa serviço) da classe User e isAccessibleFor (serviço pode ser
acessado por usuário) da classe Service. O diagrama de atividade para cada um deles é disposto a
seguir.
28
Figura 6: Diagrama de Atividade accessService (Usuário acessa serviço)
O fluxo é relativamente simples: invoca-se o método accessService passando como
parâmetro a classe de fonte de dados aos serviços, a classe de fonte de dados a associações de
serviços a usuários, o serviço sendo acessado e se é extensível ou não.
A classe de fonte de dados de serviço, é qualquer classe que implemente
IServiceDataSource. Esta fornecerá os dados para a carga de serviços a serem consultados, a
mesma finalidade tem o parâmetro de fonte de dados de associação de usuário com serviço que é
qualquer fonte de dados do tipo IUserServiceAttDataSource. É informado também o nome do
serviço e se a verificação é extensível ou não, por padrão a verificação sempre é extensível.
O fluxo é: inicia-se a atividade verificando se existe algum relacionamento direto
entre o usuário e o serviço em questão se o tiver retorna-se verdadeiro ou falso de acordo com a
permissão, caso contrário continua o fluxo de atividades que verifica o parâmetro extensible que
indica se deve ou não estender a pesquisa aos usuários de forma recursiva. Uma vez que
extensible é verdadeiro ele faz além da verificação normal, a verificação se um dos usuários
29
ascendentes não tem permissão de acesso, a verificação contrária, isto é verifica se um dos
serviços ascendente ao em questão não pode acessado pelo usuário criando desta forma um
estouro de pilha. O primeiro fator encontrado de associação (que pode ser permitido, GRANT, ou
negado, REVOKE) é retornado ao invocador do método, como resultado da função.
Pelo outro prisma, onde se invoca o método isAccessibleFor do serviço é feito o
mesmo processo porém iniciando do outro lado (no caso o serviço), como demonstra o diagrama
de atividade abaixo.
Figura 7: Diagrama de Atividade isAccessibleFor (serviço é acessado por usuário)
Agora que se definiram os diagramas de classe e de atividade pode-se estipular que
seqüência efetuar de modo a atingir o resultado desejado. Para o método accessService da classe
User há a seguinte seqüência:
30
Figura 8: Diagrama de Seqüência para User (accessService)
Deixa-se claro aqui então, que toda verificação de permissão será obtida
instanciando-se uma classe User, depois disso será chamado o método accessService deste objeto
que por sua vez criará um objeto da classe UserServiceAtt levando em consideração o serviço que
está requisitando acesso e o usuário requerente. Se o objeto pode ser criado (isto significa que
existe uma relação direta sem que seja preciso uma consulta aos usuários e serviços ascendentes),
o retorno será conforme ao tipo de associação (GRANT para permissão e REVOKE para
negação), caso contrário instancia-se um objeto da classe Service levando em conta o serviço que
se queira acessar. Para o serviço criado será invocado o método isAccessibleFor passando como
parâmetro às classes de DataSource e o usuário que esteja requisitando o acesso, se alguma
associação de serviço e usuário for encontrada retorna-se o valor conforme a associação. Logo
31
após criar o usuário pai (se existir) e fizer a mesma verificação (invocação do método
accessService) para assim verificar se o pai deste usuário não possui alguma associação uma vez
que o filho não a tenha.
A operação que envolve a criação de uma instância do objeto Service tem como
objetivo verificar se nenhum dos serviços superiores àquele a qual ele pertence está definido, e se
este estiver o retorno será a definição estabelecida.
A mesma lógica é aplicada ao método isAccessibleFor da classe Serviço que segue a
seqüência abaixo:
Figura 9: Diagrama de Seqüência para Service (isAccessibleFor)
O diagrama de seqüência anterior apresenta as etapas semelhantes ao exposto no
diagrama de accessService da classe User (F0igura 8), contudo o método principal é invocado ao
objeto instanciado da classe Service que fará a verificação da existência de um relacionamento
32
direto do serviço com o usuário em questão, caso não o tenha, será feito primeiro uma verificação
se nenhum dos ascendentes do usuário em questão o possui e depois partir para os ascendentes
dos objetos Service.
O propósito de existirem duas lógicas distintas, como se pode observar nos diagramas
de seqüência (Figuras 8 e 9) é a flexibilidade, assim pode-se centrar a decisão sobre o usuário no
caso da situação descrita no diagrama da Figura 9 ou centrada no serviço como fora exposto na
Figura 8.
Para demonstrar a distinção entre uma lógica e outra, considere a figura a seguir onde
se demonstra a aplicação das duas lógicas.
Figura 10: Exemplificação de Hierarquia de Usuários e Serviços
Supondo que neste caso se tenha definido permissão para o usuário nomeado de
Analista não conseguir acessar o serviço cujo nome é Manutenção, define-se também que o
Sênior possui permissão para acesso do serviço nomeado de Cadastro de Usuário.
Baseado nessas definições, fazendo as verificações usando objetos instanciados da
classe User, verifica-se que o usuário Sênior não acessa manutenção, mas se invocarmos o
método da classe Serviço perguntando se o serviço de manutenção pode ser acessado pelo usuário
Sênior o retorno será positivo.
Esta flexibilidade é exposta para que se possa definir se a análise de permissão será
feita centrada nos usuários ou nos serviços. A diferença é que centrada no usuário a verificação é
33
feita criando uma instância do serviço desejado e verificado se o usuário ou os superusuários do
usuário em questão possui algum valor de associação (GRANT ou REVOKE). Se o tiver,
estabelecem aquele como sendo a resposta caso contrário fazem o mesmo teste com o
superserviço até chegar ao serviço raiz. De outra forma, centrado no serviço, cria-se a instância
do usuário desejado e verifica todos os superserviços do serviço em questão, a fim de definir uma
resposta, se esta não existir cria-se o superusuário e faz-se o teste até chegar à raiz.
3.3 Tecnologias Utilizadas
3.3.1 Armazenamento de Dados
O sistema para armazenamento de dados usado na aplicação exemplo foi o MySQL
conforme exposto no diagrama de classes das classes que implementaram as interfaces tipo
DataSources no item 3.1.
O motivo pelo qual os testes foram feitos com a base de dados MySQL foi da
disponibilidade dos softwares envolvidos já configurados.
Nada proíbe de implementar as interfaces em classes que façam acesso a uma outra
base de dados como Oracle, MS SQL, DB2 ou Interbase. Soluções ainda mais simples como
XML ou arquivos textos separados por vírgula também podem ser implementadas.
3.3.2 Linguagens de Programação
As classes de verificação de acesso foram escritas inicialmente em PHP versão 4, mas
com o decorrer do trabalho notou-se que esta não sanava todas as necessidades principalmente
com métodos estáticos, propriedades estáticas e o conceito de interface, uma vez que a versão 4
do PHP não disponibiliza tais propriedades (um meio para contornar esta situação seria a criação
de classes que seriam herdadas usando um pouco de polimorfismo, obtendo o resultado esperado
mas sem criar um modelo condizente ao sugerido), levando-se em conta este item optou-se pela
34
versão 5 da plataforma, que tem um ambiente mais robusto no quesito orientação a objeto onde
foram desenvolvidas todas as interfaces e classes da maneira proposta inicialmente.
É importante ressaltar que é perfeitamente possível a criação do mesmo modelo
usando a versão 4 do PHP, mas é aconselhável um ambiente que possibilite ao menos a
implementação dos conceitos de herança (o que já existe na versão 4), de interface e de
encapsulamento, como por exemplo: C++, Java, C#, Object Pascal e outras.
3.4 Implementação do Modelo Proposto
A implementação do modelo foi feita em PHP por uma razão muito simples: existem
meios de verificar as permissões de acesso usando Java e .Net nas próprias plataformas o que não
acontece com PHP, por isso achou-se mais interessante a implementação de uma ferramenta
deste tipo para esta plataforma.
Inicialmente foram estipuladas as classes a serem escritas conforme se definiu no
diagrama de classes no presente trabalho.
Criadas as classes partiu-se para a lógica dos métodos destas classes, nos quais
destacam-se os dois principais métodos (isAccessibleFor da classe Service, e accessService da
classe User).
Figura 11: Código do método accessService da classe User
35
Figura 12: Código do método isAccessibleFor da classe Service
3.4.1 Integração com Aplicações já Desenvolvidas
Tendo em vista que o modelo propusera a verificação da permissão de acesso de um
usuário a um serviço ou o contrário, considerou-se que seria interessante que o usuário pudesse
efetuar esta verificação usando somente uma linha de código.
Como as classes exigem entradas de objetos como parâmetros, apresenta-se um
exemplo que de como pode ser ou não exibido determinado item em um menu fictício.
Figura 13: Exemplo do uso
Na Figura 13, atribuiu-se à propriedade active do objeto menuItem,o valor lógico
retornado da verificação de acesso do usuário “Administrador” ao serviço “Cadastro de
Usuários”.
Neste exemplo pode-se ter uma idéia ainda do que é possível fazer, que fica ainda
mais interessante quanto se tem um problema onde usuários podem ter privilégios distintos para
uma mesma função.
Cita-se como exemplo para o problema exposto no parágrafo acima o caso de
manutenção de dados de um cadastro onde é possível existir usuários que podem somente inserir
menuItem->active = User::getUser( new userDataSourceMySQL(), "Administrador" )->accessService( new UserServiceAttDataSourceMySQL(), "Cadastro de Usuários" ;
36
registros, outros inserir e alterar, outros ainda somente excluir e assim por diante. No código
abaixo se vê a solução deste problema aplicando o modelo proposto neste trabalho.
Figura 14: Exemplificação do uso do modelo junto a um cadastro de manutenção
Tendo definido que o usuário pode acessar todo cadastro de usuário e definido que
este usuário não tem acesso à exclusão, criando assim uma relação de permissão e uma relação de
negação de acesso, será exibido o item no menu de gerenciamento como exposto na Figura 12
function processOperation($operation,$data) { switch ($operation) { case INSERIR: if (User::getUser(new userDataSourceMySQL(), "Administrador" )->accessService( new UserServiceAttDataSourceMySQL(), "Inserir Cadastro de Usuários" )) return processInsertAction($data); break; case ALTERAR: if (User::getUser(new userDataSourceMySQL(), "Administrador" )->accessService( new UserServiceAttDataSourceMySQL(), "Alterar Cadastro de Usuários" )) return processUpdateAction($data); break; case EXCLUIR: if (User::getUser(new userDataSourceMySQL(), "Administrador" )->accessService( new UserServiceAttDataSourceMySQL(), "Excluir Cadastro de Usuários" )) return processDeleteAction($data); break; } return false; }
37
(por ele possuir o acesso), mas ao executar a exclusão de usuários cadastrados a resposta será
falsa, diferente a verificação da permissão de inserção ou alteração que retornará verdadeiro.
3.5 Testes e Validações
Baseada sobre a fundamentação de qualidade de software temos que um meio para
efetuar testes sobre um modelo computacional é a criação de uma checklist para efetuar os
devidos testes.
Para tanto criou-se uma base de dados com as possibilidades existentes para a
aplicação em uma situação real, isto inclui:
• atribuição de permissões diretas;
• atribuição de negação diretas;
• atribuição de permissão a subitens de itens negados;
• atribuição de negação a subitens de itens permitidos;
Para testar todas as possibilidades de forma padronizada criou-se um checklist que
prevê todas as possibilidades reais existentes sobre um software. Este checklist contém as
seguintes prerrogativas:
• Verificação se o usuário possui acesso a serviços;
• Verificação se o serviço pode ser acessado pelo usuários;
• Verificação se os usuários descendentes podem acessar os serviços atribuído
ao usuário;
• Verificação se serviços descendentes podem ser acessados pelo usuário
atribuído;
• Verificação se usuários descendentes podem acessar serviços descendentes a
serviços atribuídos ao usuário;
38
• Verificação se serviços descendentes podem ser acessados por usuários
descendentes aos serviços atribuídos ao usuário;
• Verificação se usuários descendentes podem acessar serviços descendentes
aos serviços negados ao usuário;
• Verificação se serviços descendentes podem ser acessados por usuários
descendentes aos serviço negado ao usuário;
• Verificação se usuários descendentes permitidos podem acessar serviços
descendentes àqueles que são negados para os usuários ascendentes ao em
questão;
• Verificação se serviços descendentes podem ser acessados por usuários
descendentes àqueles que são negados aos serviços ascendentes ao em
questão;
Fazendo os testes relacionados acima temos certeza de que todas as possibilidades de
permissões foram testadas inibindo assim qualquer possibilidade de erro de ordem lógica quanto
a implementação do modelo garantindo a confiabilidade de acordo com a qualidade de software.
Para facilitar estes teste fora criado um script afim de executar cada uma das
possibilidades.
3.5.1 Implementações reais com o modelo proposto
O modelo desenvolvido cria uma ampla possibilidade de implementação, dentre elas
cita-se um aplicativo para gerenciamento de conteúdo desenvolvido usando este modelo.
O website baseia-se no princípio de que se não houver um usuário autenticado, o
usuário que está acessando é chamado de público que tem um registro na tabela de usuários e
possui suas permissões configuradas para visualização do conteúdo disposto de forma pública.
39
Toda requisição a estrutura principal que faz a verificação de acesso (se o usuário
realmente pode acessar o recurso solicitado), se a resposta for negativa uma página exigindo
usuário e senha é exibida a fim de possibilitar a autenticação do usuário.
Figura 15: Exemplo de página requisitando autenticação para acesso ao recurso
solicitado.
Ao informar um usuário válido é feita uma nova requisição ao mesmo recurso,
porém, quando inicia a execução do script estrutural o usuário é validado e assim ele possui
acesso, desta forma pode acessar por exemplo o menu de manutenção como segue na figura
abaixo.
40
Figura 16: Exemplo de acesso ao menu por parte do administrador do website
A figura 16 trata do menu de gerenciamento de um usuário que possui o usuário
administrador como um de seus ascendentes e não possui nenhuma negação de serviço. Ao
possuir alguma negação, e se esta for um item mapeado pelo website como sendo um item
principal (no caso foram mapeados todos os itens do menu e relacionados a tabela de serviços
possibilitando a seleção dos nomes como fora exibido na figura sem apresentar todos os serviços
descendentes aos exibidos, como por exemplo: alteração de arquivos, exclusão de arquivos e
inserção de arquivos).
41
Para um usuário que possui acesso direto (sem que seus ascendentes tenham), são
exibidas as informações como segue na figura 17. Onde o perfil do mesmo não possui nenhuma
permissão por herdar diretamente do usuário público.
Figura 17: Exemplo de acesso ao menu de gerenciamento por parte de um usuário
comum
O mapeamento de funções criado no website, combinado com as permissões do
usuário monta um menu conforme exibido na figura 17, onde o perfil do mesmo não tem
nenhuma função senão a de desconexão e o usuário em particular possui acesso a algumas
funções em específico.
42
Figura 18: Manutenção de arquivos acessado por usuário com permissão de edição e
exclusão
Estas propriedades ativas que foram grifadas na figura 17 pois estão disponíveis para
usuários que possuem acesso a alteração e exclusão de arquivos.
43
Figura 19: Manutenção de arquivos para usuário sem permissão para exclusão ou
alteração
Já para o caso do segundo usuário que não possui acesso a exclusão e alteração de
arquivos será exibido uma lista como na figura 18 onde os itens estão desabilitados informando-o
da opção indisponível.
44
Figura 20: Formulário para alteração do arquivo selecionado
Quando um usuário que possui permissão de acesso a alteração de arquivos tenta
alterar o arquivo é exibido um formulário idêntico com o da figura 20 onde há se a possibilidade
de alteração do arquivo. Do contrário será exibida um formulário como apresentado na figura 15
para dar a possibilidade do usuário autenticar-se com um usuário diferente.
45
4 Conclusão
O presente trabalho atingiu os objetivos de acordo com o que fora proposto.
A criação do modelo possibilita um gerenciamento eficiente independente ao número
de regras de acesso a recursos. Em aplicações de grande porte este quesito se torna importante
uma vez que temos inúmeros usuários acessando diversos recursos com um grande número de
exceções de acesso particular de cada usuário.
O modelo baseado em uma estrutura hierárquica também se mostra muito eficaz em
aplicações de pequeno porte como tratado no presente documento.
A implementação se fez utilizando a linguagem PHP, o emprego de algumas técnicas
de Orientação a Objeto deixou o modelo ainda mais flexível usando implementações de
interfaces para acesso a dados de outras fontes.
A alteração de aplicativos já existentes torna-se simples, uma vez que se pode fazer a
verificação de acesso a determinado recurso em uma única linha retornando um valor lógico para
ser analisado.
46
Referências
CÂMARA, Fábio. 58 + Soluções em .Net – Florianópolis: VisualBooks, 2005
DEITEL, H.M. Perl: como programar – Porto Alegre: Bookman, 2002
DEITEL, H.M. C#: como programar – São Paulo: Pearson Education, 2003
GUSTAFSON, David A. Teoria e problemas de engenharia de software – Porto Alegre: Bookman, 2003
HUGHES, Streling. PHP Guia do Desenvolvedor – São Paulo: Berkeley Brasil, 2001
HUSTED, Ted. Struts em Ação – Rio de Janeiro: Ciência Moderna, 2004
KURNIAWAN, Budi. Java para a Web com Servlets, JSP e EJB – Rio de Janeiro: Ciência Moderna, 2002
MARCELO, Antônio. Apache – Configurando o servidor WEB para Linux – Rio do Janeiro: Brasport, 2003
O’BRIEN, James A. Sistemas de Informação e as decisões gerenciais na era da Internet – 2 ed. – São Paulo: Saraiva, 2004
PETERS, James F. Engenharia de Softwarre. – Rio de Janeiro: Campus, 2001
PLATT, David S. Iniciando Microsoft.NET – São Paulo: Makron Books, 2002
WEINBERG, Gerald M. Software com Qualidade – Volume II: medidas de primeira ordem – São Paulo: Makron Nooks, 1994.
