UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS JARIEL GUILHERME LUVIZON - PDF
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS JARIEL GUILHERME LUVIZON
Download "UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS JARIEL GUILHERME LUVIZON"
Ivan Van Der Vinne Lencastre
1 UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS JARIEL GUILHERME LUVIZON SEGURANÇA E DESEMPENHO EM APLICAÇÕES WEB UTILIZANDO JAAS, GLASSFISH E POSTGRESQL TRABALHO DE DIPLOMAÇÃO MEDIANEIRA 2011
2 JARIEL GUILHERME LUVIZON SEGURANÇA E DESEMPENHO EM APLICAÇÕES WEB UTILIZANDO JAAS, GLASSFISH E POSTGRESQL Trabalho de Diplomação apresentado à disciplina de Trabalho de Diplomação, do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CSTADS da Universidade Tecnológica Federal do Paraná UTFPR, como requisito parcial para obtenção do título de Tecnólogo. Orientador: Prof. M.Sc. Fernando Schütz. MEDIANEIRA 2011
3 Ministério da Educação Universidade Tecnológica Federal do Paraná Diretoria de Graduação e Educação Profissional Coordenação do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas TERMO DE APROVAÇÃO Segurança e desempenho em aplicações WEB utilizando JAAS, GlassFish e PostgreSQL Por Jariel Guilherme Luvizon Este Trabalho de Diplomação (TD) foi apresentado às 10:30 h do dia 14 de junho de 2011 como requisito parcial para a obtenção do título de Tecnólogo no Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, da Universidade Tecnológica Federal do Paraná, Campus Medianeira. O candidato foi arguido pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado. Prof. M.Sc. Fernando Schütz UTFPR Campus Medianeira (Orientador) Prof. Cláudio Leones Bazzi UTFPR Campus Medianeira (Convidado) Prof. Márcio Angêlo Matté UTFPR Campus Medianeira (Convidado) Prof. Juliano Lamb UTFPR Campus Medianeira (Responsável pelas atividades de TCC) A folha de aprovação assinada encontra-se na Coordenação do Curso.
4 AGRADECIMENTOS Agradeço primeiramente a toda minha família que sempre me apoiou e incentivou durante os momentos mais difíceis e deram conselhos que me fizeram superar obstáculos e seguir em frente com o trabalho. Agradeço também aos meus amigos, em especial ao Felipe e ao Leandro, com os quais eu passei vários dias trabalhando no desenvolvimento do sistema. Esse trabalho com certeza não seria possível sem a ajuda de todos os professores que participaram da minha caminhada pela UTFPR, com os quais eu aprendi muito. Guardo uma gratidão em especial a meu orientador Fernando Schütz que me orientou tanto no estágio quanto no TCC e sempre esteve disposto a ajudar, apesar das dificuldades.
5 O único lugar onde o sucesso vem antes do trabalho é no dicionário. (EINSTEIN, Albert)
6 RESUMO LUVIZON, G. Jariel. Segurança e desempenho em aplicações WEB utilizando JAAS, GlassFish e PostgreSQL Trabalho de conclusão de curso (Tecnologia em Análise e Desenvolvimento de Sistemas), Universidade Tecnológica Federal do Paraná. Medianeira A segurança e o desempenho nas aplicações WEB é algo fundamental. Este trabalho tem como foco demonstrar de maneira teórica e com exemplos práticos como deixar uma aplicação WEB segura, através do controle de autenticação e autorização utilizando JAAS (Java Authentication and Authorization Service) e explorando os recursos de segurança e backup fornecidos pelo SGBD (Sistema Gerenciador de Banco de Dados) PostgreSQL. Também será aprimorado a performance do servidor de aplicação GlassFish para melhorar o desempenho da aplicação WEB. Palavras-chave: JAAS. GlassFish. PostgreSQL. Segurança. Desempenho.
7 ABSTRACT LUVIZON, G. Jariel. Segurança e desempenho em aplicações WEB utilizando JAAS, GlassFish e PostgreSQL Trabalho de conclusão de curso (Tecnologia em Análise e Desenvolvimento de Sistemas), Universidade Tecnológica Federal do Paraná. Medianeira The safety and performance in WEB applications is fundamental. This work focuses on theoretical and demonstrate the way with practical examples how to make WEB application security by controlling authentication and authorization using JAAS (Java Authentication and Authorization Service) and exploiting the resources of security and backup provided by the DBMS (System Manager Database) PostgreSQL. Will also be improved performance of the application server GlassFish to improve performance of WEB application. Keywords: JAAS. GlassFish. PostgreSQL. Safety. Performance.
8 LISTA DE FIGURAS Figura 1 Funcionamento do JAAS Figura 2 Múltiplas conexões no PostgreSQL Figura 3 Arquitetura de um servidor de aplicação Figura 4 Relacionamento entre as tabelas estabelecimento e groups Figura 5 Configuração de um conection pool Figura 6 Configuração de um data source Figura 7 Captcha na página de cadastro Figura 8 Ativação da compressão gzip no GlassFish Figura 9 Habilitando o cache de arquivos Figura 10 Teste do Page Speed sem os recursos de compressão e cache Figura 11 Teste do Page Speed com os recursos de compressão e cache ativos 40 Figura 12 Arquivo crontab responsável por agendar tarefas... 42
9 LISTA DE QUADROS Quadro 1 Limites do PostgreSQL Quadro 2 - Configuração de um novo realm Quadro 3 - Método para criptografar senha em md Quadro 4 - Criação de roles em um arquivo sun-web.xml Quadro 5 - Configuração de um login-config e de uma error-page Quadro 6 - Configuração de uma regra de acesso Quadro 7 Formulário de login com JAAS Quadro 8 Implementação da interface PhaseListener Quadro 9 Configuração da classe SessionListener no arquivo faces-config.xml Quadro 10 Propriedades de uma JavaMail Session Quadro 11 Classe responsável por fazer o envio de s Quadro 12 Método responsável por gerar o código de bloqueio do cadastro Quadro 13 Método responsável por realizar o desbloqueio do cadastro Quadro 14 Declarando o componente Captcha em uma página.xhtml Quadro 15 Configuração das chaves pública e privada do Captcha Quadro 16 Principais tipos de mime type Quadro 17 Script shell responsável por realizar o dump da base de dados Quadro 18 Script shell que faz a restauração do banco de dados... 42
10 LISTA DE SIGLAS ACID - Atomicidade, Consistência, Isolamento e Durabilidade API - Application Programming Interface AVI - Audio Video Interleave BMP - BitMap CAPTCHA - Completely Automated Public Turing Test to Tell Computers and Humans Apart CSS - Cascading Style Sheets CDDL - Common Development and Distribution License EJB - Enterprise JavaBean GB - GigaByte GIF - Graphics Interchange Format HTML - HyperText Markup Language HTTP - Hypertext Transfer Protocol ISO - International Organization for Standardization JAAS - Java Authentication and Authorization Service JDBC - Java Database Connectivity JEE - Java Enterprise Edition JPEG/JPG - Joint Photographic Experts Group JS - JavaScript JSF - Java Server Faces MVCC - Multiversion Concurrency Control ODBC - Open Data Base Connectivity OS - Operating System PAM - Pluggable Authentication Module PITR - Point-in-time Recovery PNG - Portable Network Graphics SDK - Software Development Kit SGBD - Sistema Gerenciador de Banco de Dados SQL - Structured Query Language TB - TeraByte URL - Uniform Resource Locator
11 XML - Extensible Markup Language XHTML - extensible Hypertext Markup Language WAL - Write Ahead Logs
12 SUMÁRIO 1 INTRODUÇÃO OBJETIVO GERAL OBJETIVOS ESPECÍFICOS JUSTIFICATIVA ESTRUTURA DO TRABALHO REVISÃO BIBLIOGRÁFICA SEGURANÇA EM APLICAÇÕES WEB Autenticação Autorização JAAS SEGURANÇA EM UM SGBD POSTGRESQL SERVIDORES DE APLICAÇÃO ESTUDO EXPERIMENTAL MATERIAIS E MÉTODOS REQUISITOS DE SEGURANÇA DA APLICAÇÃO CONFIGURAÇÃO DO JAAS Esquema do Banco de Dados Configurando o JAAS no GlassFish Configurando o JAAS na Aplicação OUTROS MECANISMOS DE SEGURANÇA Phase Listener Validação de cadastro por Captcha OTIMIZANDO O DESEMPENHO DA APLICAÇÃO Compressão GZIP Habilitando o cache de arquivos AUTOMATIZAÇÃO DE BACKUPS CONSIDERAÇÕES FINAIS CONCLUSÃO... 43
13 4.2 TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS... 45
14 11 1 INTRODUÇÃO O acesso a Internet tornou-se algo praticamente indispensável no mundo atual. Transações bancárias, e-commerce, estudo a distancia e outras infinidades de recursos estão disponíveis na Rede. E como não poderia ser diferente de outros aspectos da vida, a segurança é fundamental e deve ser uma das principais preocupações na hora de desenvolver uma aplicação WEB. Uma aplicação típica, geralmente, está distribuída em vários servidores, rodando diversos aplicativos e para funcionar na velocidade adequada, a aplicação precisa de que as interfaces entre os diversos sistemas sejam construídas com a premissa que os dados passados através da mesma são confiáveis e não hostis. O calcanhar de Aquiles destas aplicações é a necessidade de haver confiança entre os diversos subsistemas e é disso que os hackers e outros cibercriminosos se aproveitam (GARTNER, 2004). Entretanto, a segurança de uma aplicação WEB não se baseia somente em proteger-se de ataques externos e de controlar o acesso de usuários autenticados. Além de tudo isso a aplicação deve ser capaz de manter a integridade dos dados dos usuários e garantir que eles permaneçam intactos independente do que ocorra. Aliado a segurança, outro fator importante em uma aplicação WEB é o desempenho. De nada adianta uma aplicação ser segura em vários níveis se a mesma não tiver um desempenho que agrade o usuário. 1.1 OBJETIVO GERAL Este trabalho objetiva desenvolver uma aplicação com a finalidade de testar o nível de segurança e o desempenho de aplicações WEB utilizando o serviço de autenticação e segurança em Java (JAAS), o servidor de aplicação GlassFish e o banco de dados PostgreSQL.
15 OBJETIVOS ESPECÍFICOS Os objetivos específicos são: Realizar uma pesquisa bibliográfica sobre as ferramentas JAAS, GlassFish e PostgreSQL; Desenvolver uma aplicação WEB Java EE (Enterprise Edition). Implementar o mecanismo de segurança JAAS na aplicação; Apresentar um esquema que vise a otimização de desempenho e segurança dos dados explorando os recursos oferecidos pelo servidor de aplicação GlassFish e do SGBD PostgreSQL. Testar na prática o desempenho e a segurança da aplicação após a configuração dos mecanismos de otimização de performance e segurança fornecidos pelo GlassFish. 1.3 JUSTIFICATIVA Existem várias maneiras de fazer o controle de autorização e autenticação de usuários em uma aplicação WEB. O JAAS (Java Authentication and Authorization Service) é um conjunto de APIs que permite que as aplicações Java tenham um controle de autenticação e de acesso. O JAAS implementa uma versão Java do framework padrão Pluggable Authentication Module (PAM), e suporta autorização baseada em usuário. Isso permite que aplicações fiquem independentes desse controle de segurança. Serve para controlar permissões de vários tipos de recursos: arquivos, diretórios, conteúdos, URLs (VIANA, 2006). Como esse padrão de segurança é executado em nível de servidor de aplicação é importante utilizar um que forneça diversos recursos e que possua um bom desempenho. O GlassFish é um servidor de aplicação Java EE desenvolvido pela Sun Microsystems. Ele fornece toda uma infraestrutura de serviços como, por exemplo, a criação de pool de conexões ao banco de dados e ao deploy de várias aplicações no mesmo servidor (JEFFERSON, 2008).
16 13 A escolha do SGBD é um outro ponto importante pois é ele que irá guardar todos os dados dos usuários. O PostgreSQL é um poderoso sistema gerenciador de banco de dados objeto-relacional de código aberto. Ele possui vários recursos que não apenas garantem a integridade dos dados, como também auxiliam no desempenho da aplicação. Unindo essas três ferramentas (JAAS, GlassFish e PostgreSQL) é possível desenvolver uma aplicação segura, estável e com um ótimo desempenho, podendo assim aumentar o nível de aceitação da aplicação perante ao usuário. 1.4 ESTRUTURA DO TRABALHO O presente trabalho possui cinco capítulos, sendo que o primeiro trata sobre a contextualização do tema abordado e também define os objetivos e a justificativa do projeto. O segundo busca fornecer um conceito teórico sobre as tecnologias e ferramentas que foram utilizadas no desenvolvimento do mesmo, como o JAAS (Java Authentication and Authorization Service), o servidor de aplicação GlassFish e o Sistema Gerenciador de Banco de Dados PostgreSQL. O capítulo seguinte contempla o estudo experimental, onde foi mostrado na prática a solução para os requisitos de segurança e desempenho da aplicação desenvolvida. As conclusões finais sobre o projeto e as sugestões para trabalhos futuros são abordadas no capítulo quatro. Por fim, no último capítulo, estão as referências bibliográficas que fizeram parte do embasamento teórico do projeto.
17 14 2 REVISÃO BIBLIOGRÁFICA Este capítulo tem como objetivo fornecer um referencial teórico sobre as tecnologias utilizadas para o desenvolvimento do estudo experimental, que são o banco de dados PostgreSQL, o servidor de aplicações GlassFish e o mecanismo de segurança JAAS. Também serão abordados conceitos sobre os temas segurança e desempenho em aplicações WEB. 2.1 SEGURANÇA EM APLICAÇÕES WEB A utilização de aplicativos WEB é algo que, a cada dia que passa, se torna cada vez mais indispensável. A maioria das pessoas prefere acessar uma aplicação on-line que permite realizar as mesmas ou até mais tarefas que um aplicativo desktop fornece e isso tudo sem ter o transtorno de precisar instalar o programa no próprio computador (LINGHAM, 2007). Tanto as aplicações desktop como as WEB precisam cuidar de algo que é essencial, a segurança. Uma das principais vantagens desta ultima que é poder ser acessada de qualquer lugar que tenha acesso à Internet, se torna um dos seus pontos fracos. Aplicações WEB são formadas por inúmeros recursos, como páginas dinâmicas, estáticas, imagens, downloads, uploads, processos, relatórios etc. Grande parte desses recursos não podem estar disponível para qualquer pessoa que tentar acessá-lo e para isso as aplicações WEB devem controlar o acesso dos usuários a estes recursos (FRANZINI, 2009). Para que essas aplicações estejam seguras existem alguns princípios que devem ser considerados: Autenticação: O processo de provar a sua identidade para uma aplicação; O controle de acesso de recursos: Os meios pelos quais as interações com os recursos são limitados para os usuários, papéis (roles), ou programas com o objetivo de impor a integridade, confidencialidade, ou restrições de disponibilidade;
18 15 A integridade dos dados: Os meios de provar que um terceiro não alterou informações enquanto a mesma estava em trânsito; Confidencialidade e privacidade dos dados: Os meios utilizados para assegurar que a informação feita é disponível somente para usuários que estão autorizados a acessá-lo (BROWN et al, 2005) Autenticação Desde o surgimento da Internet, ela se mostrou como um mecanismo de anonimato, onde as pessoas poderiam se passar por outras ou até mesmo não se passar por ninguém. Autenticação é o processo onde uma pessoa prova quem ela realmente é com o intuito de obter alguma informação ou executar alguma ação (FRANZINI, 2009). A autenticação geralmente é feita em uma tela de login onde a pessoa informa suas credencias (geralmente usuário e senha) e caso forem corretas, ela tem sua autenticação confirmada pela aplicação Autorização Autorização consiste na etapa de dar permissão à pessoa autenticada para acessar algum recurso ou realizar alguma ação. Em sistemas onde existem vários tipos de usuários um administrador de sistemas definirá quais usuários terão acesso e quais privilégios de execução esses terão. (FRANZINI, 2009). Segundo Franzini (2009), O mecanismo de autorização é muitas vezes visto como composto de dois momentos: Ato de atribuir permissões ao usuário do sistema no momento de seu cadastro, ou posterior. Ato de checar as permissões que foram atribuídas ao usuário no momento de seu acesso.
19 JAAS O Serviço de Autenticação e Autorização JavaTM (JAAS) foi introduzido como um pacote opcional (extensão) para o JavaTM 2 SDK, Standard Edition (J2SDK), v1.3. Ele também está integrado no J2SDK desde a versão 1.4. (JAAS REFERENCE GUIDE, 2001). O JAAS é responsável por definir um padrão JEE de regras de como a aplicação WEB irá definir e gerenciar o controle de acesso. Há diferentes níveis em opções de autenticação que são baseados na definição de roles (FRANZINI, 2009). A base de dados onde ficam armazenados os usuários credenciados pode estar em arquivos xml, bancos de dados relacionais, etc. (FRANZINI, 2009). Utilizando o JAAS é possível simplificar o desenvolvimento de segurança de uma aplicação Java WEB, colocando uma camada de abstração entre o aplicativo e os diferentes mecanismos de autorização e autenticação. Essa independência de plataformas e algoritmos permite a utilização de mecanismos de segurança diferentes, sem modificar seu código em nível de aplicação (MUSSER et al, 2009). O modulo de autenticação do JAAS está em nível de servidor de aplicação, por isso ele será executado por esse último, antes mesmo de acessar a aplicação (VIANA, 2006). A Figura 1 mostra o funcionamento do JAAS entre as camadas de uma aplicação WEB. Figura 1 Funcionamento do JAAS Fonte: Oracle (2008)
20 SEGURANÇA EM UM SGBD A segurança de um banco de dados é algo de extrema importância pois eles guardam um patrimônio muito valioso que é a informação. Quando há um problema de segurança em um SGBD são os dados que estão ameaçados, dados esses que podem ser senhas bancárias, números de cartões de credito, entre outras informações confidenciais. Segurança em SGBD não se refere apenas ao banco de dados, diz respeito a toda a cadeia tecnologia associada à aplicação, onde um elo fraco põe em risco o conjunto todo. Para que isso não aconteça não se deve pensar no SGBD isoladamente. É necessário pensar no equipamento onde o SGBD se encontra, no OS onde ele está instalado, na própria instalação do SGBD, nas informações contidas no banco de dados, nas aplicações que vão acessar o banco de dados e também no usuário que precisa destas informações (TELLES, 2008). Existem alguns aspectos que caminham lado a lado com o conceito de segurança em um SGBD: integridade, backup e controle de acesso. Integridade: engloba as propriedades ACID (Acrônimo de Atomicidade, Consistência, Isolamento e Durabilidade). É necessário garantir que os dados contidos no banco de dados se mantenham intactos independente do que ocorra. Mesmo que aconteça algum problema de indisponibilidade durante um determinado tempo é fundamental que quando o problema seja resolvido os dados voltem exatamente como estavam. Para garantir a integridade também é fundamental usar as restrições de integridade (primary key, foreign key, index, etc), pois caso ocorra um erro do usuário ou da aplicação essas restrições vão impedir que os dados sejam corrompidos (TELLES, 2008). Backup: existe como forma de prevenir para quando os dados forem perdidos acidentalmente, seja por falha física, ou por falha humana, exista uma cópia desses dados. O backup garante a integridade dos dados, de configurações, de arquivos de usuários, etc. Os backups devem fazer parte da rotina de operação dos sistemas e seguir uma política determinada. É interessante faze-los de maneira automatizada para reduzir o seu impacto sobre o trabalho dos administradores e operadores de sistemas (RIBEIRO, 2009).
21 18 Controle de Acesso: Segundo Telles (2008), é a capacidade de que as informações disponíveis no banco de dados estejam disponíveis para as pessoas corretas, que terão permissão de acesso apenas às operações permitidas para o seu perfil. Normalmente o controle de acesso é feito a partir de objetos do banco de dados, porém é possível restringir o acesso, por exemplo, a apenas algumas linhas de uma tabela. Esse controle pode também limitar os recursos utilizados no banco de dados, como conexões ativas, memória, processador, etc (TELLES, 2008). 2.4 POSTGRESQL O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional de código aberto (POSTGRESQL, 2011). Ele foi baseado no POSTGRES Versão 4.2 desenvolvido pelo Departamento de Ciência da Computação da Universidade da Califórnia em Berkeley, o qual foi pioneiro em vários conceitos que somente se tornaram disponíveis muito mais tarde em alguns sistemas de banco de dados comerciais. (DOCUMENTAÇÃO DO POSTGRESQL 8.0, 2005). O PostgreSQL Tem mais de 15 anos de desenvolvimento ativo e uma arquitetura que comprovadamente ganhou forte reputação de confiabilidade, integridade de dados e conformidade a padrões. Roda em todos os grandes sistemas operacionais, incluindo GNU/Linux, Unix (Mac OS X, Solaris), e MS Windows (POSTGRESQL, 2011). É totalmente compatível com ACID, tem suporte completo a chaves estrangeiras, junções (joins), visões, triggers e procedimentos armazenados (em múltiplas linguagens). Inclui a maior parte dos tipos de dados do ISO SQL:1999, incluindo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, e TIMESTAMP. Suporta também o armazenamento de objetos binários, incluindo figuras, sons ou vídeos. Possui interfaces nativas de programação para C/C++, Java, Net, Perl, Python, Ruby, ODBC, entre outros, e uma excepcional documentação (POSTGRESQL, 2011). Como um banco de dados de nível corporativo, o PostgreSQL possui funcionalidades sofisticadas como o controle de concorrência multiversionado
22 19 (MVCC), recuperação em um ponto no tempo (PITR), tablespaces, replicação assíncrona, transações agrupadas (savepoints), backup online, um sofisticado planejador de consultas e registrador de transações sequencial (WAL) para tolerância a falhas (POSTGRESQL, 2011). É altamente escalável, tanto na enorme quantidade de dados que pode gerenciar, quanto no número de usuários concorrentes que pode acomodar. Existem sistemas ativos com o PostgreSQL em ambiente de produção que gerenciam mais de 4TB de dados (POSTGRESQL, 2011). O Quadro 1 mostra alguns dos limites do PostgreSQL. Limite Valor Tamanho máximo do banco de dados Tamanho máximo de uma tabela Tamanho máximo de uma linha Tamanho máximo de um campo Máximo de linhas por tabela Máximo de colunas por tabela Máximo de índices por tabela Ilimitado 32 TB 1.6 TB 1 GB Ilimitado dependendo do tipo de coluna Ilimitado Quadro 1 Limites do PostgreSQL Fonte: Adaptado de: POSTGRESQL (2011) O PostgreSQL utiliza o modelo de arquitetura cliente-servidor. Uma sessão do PostgreSQL consiste em dois processos: Um processo servidor, que é responsável por gerenciar os arquivos de banco de dados. Ele recebe conexões dos aplicativos cliente com o banco de dados e executa ações no mesmo em nome dos clientes. O programa servidor de banco de dados se chama postmaster; O outro processo é o aplicativo cliente do usuário (frontend) que deseja executar operações no banco de dados. Os aplicativos cliente podem ser dos mais variados tipos: um aplicativo gráfico, um servidor WEB que acessa o banco de dados para mostrar resultados nas páginas WEB, ou então uma ferramenta especializada para manutenção do banco de dados. Alguns
23 20 desses aplicativos cliente são fornecidos na distribuição do PostgreSQL, porém a grande maioria é desenvolvido pelos usuários (DOCUMENTAÇÃO DO POSTGRESQL 8.0, 2005). O servidor PostgreSQL pode tratar várias conexões simultâneas de clientes. Para esta finalidade é iniciado um novo processo (fork) para cada conexão. A partir desse momento, o cliente e o novo processo servidor se comunicam sem intervenção do processo postmaster original. Portanto, o postmaster está sempre executando aguardando por novas conexões dos clientes, enquanto os clientes e seus processos servidores associados surgem e desaparecem (DOCUMENTAÇÃO DO POSTGRESQL 8.0, 2005). A Figura 2 mostra duas conexões simultâneas de clientes no PostgreSQL. Figura 2 Múltiplas conexões no PostgreSQL Fonte: PostgreSQL Architectural Concepts 2.5 SERVIDORES DE APLICAÇÃO Os servidores de aplicação são softwares responsáveis por fornecer toda uma infraestrutura de serviços para o desenvolvimento e execução de uma aplicação distribuída. Uma das vantagens que eles possuem em relação ao modelo clienteservidor é de oferecer serviços implementados por eles e que estão disponíveis aos desenvolvedores, fazendo com que esses últimos dediquem-se mais no
24 21 desenvolvimento da lógica de negócio do que com aspectos de infraestrutura (APPLICATION SERVERS, 2003). De um modo geral esses serviços diminuem a complexidade do desenvolvimento, controlam o fluxo de dados, aprimoram o desempenho e gerenciam a segurança. Os servidores de aplicações predispõem a utilização da arquitetura conhecida como n-camadas (cliente, servidor de aplicação e banco de dados) permitindo aproveitar melhor as características de cada componente. O Front-End é a primeira camada e geralmente são browsers, que servem para apresentação da aplicação e fazem algumas validações. A segunda camada é a aplicação em si, que é executada no servidor de aplicação e a terceira é o servidor de banco de dados (APPLICATION SERVERS, 2003). A Figura 3 exemplifica a arquitetura de um servidor de aplicação. Figura 3 Arquitetura de um servidor de aplicação Fonte: JavaEE: Conceitos Básicos (2010) GlassFish é um servidor de aplicações baseado na Plataforma Java e tecnologia Enterprise Edition (Java EE) para o desenvolvimento e execução de aplicações e serviços WEB, oferecendo desempenho, confiabilidade, produtividade e
25 22 facilidade(glassfish, 2009). É um servidor de aplicação de código aberto (open source) disponível gratuitamente e está licenciado sob Common Development and Distribution License (CDDL) (HEFFELFINGER, 2010). Atualmente o GlassFish se encontra na versão 3.1 sendo o primeiro servidor de aplicação a dar suporte total a especificação Java EE 6. A sua nova versão conta com funcionalidades que adicionam características como alta disponibilidade, escalabilidade e tolerância a falhas, que são fundamentais para um servidor de produção que hospede aplicações de médio e grande porte (SOUZA, 2011). Além das características citadas a versão 3.1 conta com outra serie de características e funcionalidades: Evocação dinâmica de serviços (somente os serviços utilizados são iniciados); Melhorias de extensibilidade, tanto no servidor quanto na interface de administração; Ciclos de inicialização e implantação (deploy) 29% mais rápidos que na versão 3.0.1; Sessão, Stateful Session Beans e EJB Timers são preservados entre redeploys; Melhor integração com ferramentas (NetBeans, Eclipse, plug-in Maven para testes unitários); Desempenho da funcionalidade de alta disponibilidade 34% melhor do que a versão 2.1.1; Administração centralizada dos clusters, com escalabilidade melhorada (até 100 instâncias gerenciadas); Suporte a autenticação via PAM; Suporte a upgrade da versão 2.x ou 3.x para a 3.1; Mais funcionalidades disponíveis na versão comercial do GlassFish (Oracle GlassFish Server), como interoperabilidade com WEBSphere e WEBLogic, backup e recuperação, analisador de desempenho, balanceamento de carga, etc (SOUZA, 2011). O GlassFish ainda fornece suporte para a criação e administração de realms. Um realm é um repositório de usuários e grupos que possui mecanismos para
26 23 identificar usuários válidos para uma aplicação (JAVA EE 5 TUTORIAL, 2010). É importante definir alguns conceitos que compõe um realm: Usuário (User): um usuário é um indivíduo com uma identidade que foi definida no servidor de aplicação. Em uma aplicação WEB, um usuário pode ter um conjunto de papéis (roles) associados a essa identidade, que lhes permite acessar todos os recursos protegidos por essas funções. Os usuários podem ser associados com um grupo de usuários; Grupo (Group): um grupo pode ser definido como um grupo de usuários que possuem características em comum; Pápeis (Roles): Uma Role pode ser definida como um conjunto de privilégios que pode ser associado a um determinado grupo de usuários. Uma role pode ser comparada a uma chave que pode abrir um cadeado. Muitas pessoas podem ter uma cópia da chave e para a fechadura não importa quem a pessoa é, só interessa que ela tenha a chave certa (JAVA EE 5 TUTORIAL, 2010).
27 24 3 ESTUDO EXPERIMENTAL A aplicação WEB desenvolvida para este trabalho se baseia em uma agenda on-line, onde uma pessoa poderia cadastrar seu estabelecimento (Exemplo: uma clínica de dentistas). Também seria possível cadastrar os funcionários desse estabelecimento e cada funcionário teria sua agenda onde seriam marcados os horários das suas consultas. 3.1 MATERIAIS E MÉTODOS Para o desenvolvimento deste projeto, foi realizada uma ampla pesquisa bibliográfica, além de diversas consultas em sites especializados no assunto sobre segurança e desempenho em aplicações WEB, a fim de dar subsídios suficientes à implementação das tecnologias em estudo. Para demonstrar o funcionamento e as configurações dos mecanismos de segurança e desempenho que vão ser descritos nos próximos capítulos foi desenvolvida uma aplicação WEB na plataforma Java EE 6, utilizando também alguns recursos do PrimeFaces 2.2, que é uma biblioteca de componentes para JSF 2.0. Foi utilizado também o mecanismo de autenticação e autorização do Java (JAAS). O servidor de aplicação utilizado foi o GlassFish Server Open Source Edition 3 e o banco de dados foi o PostgreSQL 9.0. Também foram utilizadas algumas funcionalidades do sistema operacional Linux. 3.2 REQUISITOS DE SEGURANÇA DA APLICAÇÃO A aplicação WEB desenvolvida tem a necessidade de fornecer os seguintes requisitos de segurança e desempenho: Impedir que usuários não cadastrados ou não autorizados acessem páginas ou recursos restritos;
28 25 Fazer com que o usuário tenha que efetuar login novamente no sistema caso a sessão fique mais de 20 minutos inativa; Fazer a validação de cadastro por para impedir que sejam cadastrados usuários com s que não existem; Implementar um mecanismo para impedir que programas automáticos não consigam realizar cadastros e com isso possam sobrecarregar a aplicação; Otimizar o desempenho da aplicação para aumentar o nível de satisfação do usuário; Realizar backups automaticamente para que essa tarefa não precise ser delegada a uma pessoa. 3.3 CONFIGURAÇÃO DO JAAS O primeiro mecanismo de segurança a ser implantado será o JAAS. Ele atenderá o primeiro requisito de segurança, que é impedir que usuários não cadastrados ou não autorizados acessem páginas ou recursos restritos. As configurações para a implementação do JAAS acontecem em três lugares: no banco de dados, nas configurações do GlassFish e na aplicação em si Esquema do Banco de Dados A criação das tabelas que serão usadas para definir os usuários e os grupos de usuários faz parte do primeiro passo para a configuração do JAAS. A tabela estabelecimento será a tabela onde estarão guardados os dados dos usuários da aplicação, tendo como atributos fundamentais para a configuração do JAAS os campos login e senha. A tabela groups tem apenas dois campos: o campo idgroup onde serão inseridos os grupos de usuários que serão definidos na aplicação (admins e users) e o campo login que é uma chave estrangeira do atributo login da tabela
29 26 estabelecimento. Essa tabela vai ter uma chave composta formada por esses dois campos (idgroup e login) para que um usuário não seja associado duas vezes a um mesmo grupo. É importante ressaltar que as regras de acesso (roles) que serão feitas na aplicação vão ser aplicadas aos grupos de usuários e não aos usuários em si. A Figura 4 apresenta o relacionamento entre as tabelas estabelecimento e groups. Figura 4 Relacionamento entre as tabelas estabelecimento e groups Configurando o JAAS no GlassFish Com o banco de dados criado e configurado é necessário criar um pool de conexão (connection pool) e um data source que fará a conexão com esse database. Essas configurações são feitas no painel de administração do GlassFish que pode ser acessado em qualquer navegador WEB através do endereço localhost:4848. A criação de connection pools é possível através do recurso JDBC Connection Pools e um exemplo de configuração pode ser verificado na Figura 5. Ainda na configuração do connection pool, deve-se informe as propriedades
30 27 especificas do banco de dados, como o nome, a senha e o usuário do database. As demais propriedades podem ser as padrões. Figura 5 Configuração de um conection pool Agora é necessário criar o data source que irá utilizar o connection pool que foi feito anteriormente. Essa configuração é possível através do recurso JDBC Resources. A Figura 6 mostra um exemplo das propriedades de um novo data source. Figura 6 Configuração de um data source Depois de criado o data source podemos configurar o jdbcrealm que será usado na aplicação. O GlassFish fornece o recurso de criação de realms, sendo possível visualizar no Quadro 2 algumas propriedades importantes na hora de criação de um novo realm.
31 28 Propriedade Realm Name Class Name JAAS Context JNDI User Table User Name Column Password Column Group Table Group Name Column Database User Database Password Digest Algorithm Valor agenda-jaas-realm com.sun.enterprise.security.auth.realm.jdbc.jdbcrealm jdbcrealm jdbc/agendads estabelecimento login senha groups idgroup postgres postgres md5 Quadro 2 - Configuração de um novo realm É importante que o algoritmo de criptografia (Digest Algorithm) configurado no realm, seja o mesmo que será usado para criptografar a senha do usuário que irá ser inserida no banco de dados. O Quadro 3 mostra o método criado na aplicação que é encarregado por criptografar em md5 a senha do usuário na hora do cadastro. MD5 é um algoritmo de hash unidirecional e, portanto, uma vez criptografados, os dados não podem mais ser descriptografados. 1 public static String tomd5(string senha) { 2 MessageDigest md; 3 String senhamd5 = senha; 4 try { 5 md = MessageDigest.getInstance("MD5"); 6 BigInteger hash = new BigInteger(1, 7 md.digest(senha.getbytes("utf- 7 8"))); 8 senhamd5 = hash.tostring(16); 9 while (senhamd5.length() < 32) 10 { 11 senhamd5 = "0" + senhamd5; 12 } 13 } 14 catch (NoSuchAlgorithmException e) {} catch 15 (UnsupportedEncodingException e) {} 16 return senhamd5; } Quadro 3 - Método para criptografar senha em md5
32 Configurando o JAAS na Aplicação A configuração na aplicação é a ultima parte da implantação do mecanismo de segurança JAAS. Essa configuração é feita basicamente em dois arquivos da aplicação WEB: no web.xml e no sun-web.xml. Primeiramente será criado as roles que farão parte da aplicação. Essas roles serão associadas aos grupos de usuários e não diretamente aos usuários. Um ponto importante é que uma role pode estar associada a mais de um grupo de usuário. O Quadro 4 mostra um exemplo de como criar roles em um arquivo sunweb.xml 1 <security-role-mapping> 2 <role-name>user-role</role-name> 3 <group-name>admins</group-name> 4 <group-name>users</group-name> 5 </security-role-mapping> 6 7 <security-role-mapping> 8 <role-name>admin-role</role-name> 9 <group-name>admins</group-name> 10 </security-role-mapping> Quadro 4 - Criação de roles em um arquivo sun-web.xml Como pode ser visto no Quadro 4, o grupo admins além de estar associado a role admin-role está também na user-role. Isso foi feito para que o grupo admins tenha acesso a todas as páginas, caso contrário ele seria impedido de acessar uma página que está controlada pela role user-role. Esses grupos serão os mesmos que estarão na tabela groups no banco de dados. Para fazer essa associação, no momento do cadastro de um novo usuário, deve definir qual será seu grupo (admins ou users) e gravá-lo na tabela groups. A tarefa seguinte consiste na configuração do arquivo web.xml. É nele onde dizemos qual será o método de autenticação (none, basic, form ou digest/certificate) e qual o nome do realm associado. O Quadro 5 mostra a configuração de um login-config e de uma error-page.
33 30 1 <login-config> 2 <auth-method>form</auth-method> 3 <realm-name>agenda-jaas-realm</realm-name> 4 <form-login-config> 5 <form-login-page>/views/login/login-jaas.jsf</form-login-page> 6 <form-error-page>/views/login/login-error-jaas.jsf</form-error-page> 7 </form-login-config> 8 </login-config> 9 10 <error-page> 11 <error-code>403</error-code> 12 <location>/views/login/permission-error.jsf</location> 13 </error-page> Quadro 5 - Configuração de um login-config e de uma error-page No exemplo do Quadro 5, o método de autenticação utilizado foi FORM, ou seja, é necessário informar qual vai ser a página de login e a página de erro de login, caso o usuário informe dados incorretos. Também foi configurada uma página de erro para o código 403, que será disparado caso um usuário seja autenticado porém não esteja autorizado a acessar um determinado recurso. Ainda no arquivo web.xml existe uma configuração importante, que é utilizar as roles criadas no arquivo sun-web.xml para definir as regras de acesso na aplicação. O Quadro 6 mostra o exemplo da configuração de uma regra de acesso. 1 <security-constraint> 2 <web-resource-collection> 3 <web-resource-name>agenda do estabelecimento</web-resource-name> 4 <url-pattern>/views/agenda/*</url-pattern> 5 <http-method>get</http-method> 6 <http-method>post</http-method> 7 </web-resource-collection> 8 <auth-constraint> 9 <role-name>user-role</role-name> 10 </auth-constraint> 11 </security-constraint> Quadro 6 - Configuração de uma regra de acesso Como pode ser visto no Quadro 6 foi criado um recurso onde está definido que todas as urls a partir do caminho /views/agenda/ serão restritas a role user-role. É possível criar quando regras forem necessárias, tudo depende da necessidade de controle que a aplicação precisa ter. Por fim, deve-se criar a página de login. Essa página é composta por um formulário simples. Um detalhe importante e obrigatório é colocar os nomes do campo login e senha como j_username e j_password e na action do form
34 31 colocar j_security_check para que o servidor de aplicação identifique que se trata de uma tentativa de login e faça a autenticação necessária. O Quadro 7 mostra o exemplo de um formulário de login com JAAS. <form method="post" action="j_security_check" class="login"> <h3>digite seu login e senha:</h3> <input type="text" id="username" name="j_username" value="usuario" /> <input type="password" id="password" name="j_password" value="senha" /> <input type="submit" name="submit" value="login" /> </form> Quadro 7 Formulário de login com JAAS Após um usuário ser autenticado pelo servidor de aplicação ele irá ter suas credenciais guardadas em uma sessão e não precisará se autenticar novamente até que a sessão termine ou expire. 3.4 OUTROS MECANISMOS DE SEGURANÇA O JAAS é o principal mecanismo de segurança que foi implementado nesse estudo experimental. Entretanto, ele não atende a necessidade de todos os requisitos de segurança que foram especificados. Para atender essas necessidades foram implementados outros mecanismos mais simples, porém eficazes Phase Listener Para atender ao requisito que especifica que um usuário não deve ficar mais de 20 minutos inativo, foi implementando um Phase Listener. O Phase Listener é um recurso especifico do JSF que é responsável por interceptar e oferecer mecanismos de manipulações referentes às mudanças de eventos ocorridas no ciclo de vida da especificação (FRANZINI, 2009). Para utilizar esse recurso, primeiro é necessário criar uma classe que implemente a interface PhaseListener. Essa interface possui três métodos:
35 32 afterphase(), beforephase() e getphaseid(). No Quadro 8 é possível ver um exemplo da implementação do Phase Listener. 1 public class SessionListener implements PhaseListener { 2 3 private static final long serialversionuid = 1L; 4 5 public void afterphase(phaseevent event) { 6 FacesContext facescontext = event.getfacescontext(); 7 HttpSession session = (HttpSession) 8 facescontext.getexternalcontext().getsession(false); 9 10 if(facescontext.getexternalcontext().getuserprincipal()!= null) 11 { 12 long lastacessedtime = Calendar.getInstance().getTimeInMillis() 13 - session.getlastaccessedtime(); 14 lastacessedtime = TimeUnit.MILLISECONDS.toMinutes(lastAcessedTime); if(lastacessedtime > 20) 17 { 18 session.invalidate(); 19 String loginpage = "/views/login/login-jaas.jsf"; 20 ExternalContext externalcontext = 21 facescontext.getexternalcontext(); 22 try { 23 externalcontext.redirect(externalcontext.getrequestcontextpath() 24 +loginpage); 25 } catch (IOException e) { 26 e.printstacktrace(); 27 } 28 } 29 } 30 } public void beforephase(phaseevent event) {} 33 public PhaseId getphaseid() { 34 return PhaseId.RESTORE_VIEW; 35 } 36 } Quadro 8 Implementação da interface PhaseListener Na classe mostrada no Quadro 8, a lógica de negócio para controlar o tempo de sessão do usuário é implementado no método afterphase(), onde será feita uma validação para verificar se existe um usuário na sessão. Caso o usuário exista, será verificado o tempo que ele está inativo (não fez nenhuma requisição na aplicação) e se ele estiver por mais de 20 minutos inativo a sessão será terminada e o usuário será redirecionado para a página de login. A classe SessionListener será chamada na primeira fase do ciclo de vida do JSF, chamada de Restore View.
36 33 Depois de criada, essa classe deve ser configurada no arquivo facesconfig.xml para que a aplicação saiba que se trata de uma implementação da interface PhaseListener. O Quadro 9 mostra um exemplo dessa configuração. 1 <lifecycle> 2 <phase-listener>agenda.utils.sessionlistener</phase-listener> 3 </lifecycle> Quadro 9 Configuração da classe SessionListener no arquivo faces-config.xml Validação de cadastro por Fazer uma validação de novos cadastros por é uma maneira eficiente para evitar que pessoas de má fé se registrem inúmeras vezes com s que não existem, deixando o banco de dados com informações inconsistentes e que não poderão ser utilizadas. Para implementar essa validação por , primeiro é necessário configurar o servidor de aplicação para que ele possa enviar s. No painel de administração do GlassFish é possível criar um recurso chamado de JavaMail Session, que implementa essa funcionalidade. O Quadro 10 mostra as propriedades de uma JavaMail Session que, nesse caso é configurada levando em conta as propriedades do serviço de do gmaill. Propriedade Valor JNDI Name: Mail Host: smtp.gmail.com Default User Default Return Address mail.smtp.socketfactory.port 465 mail.smtp.port 465 mail.smtp.socketfactory.fallback false mail.smtp.auth true mail.smtp.password lejafetcc mail.smtp.socketfactory.class javax.net.ssl.sslsocketfactory Quadro 10 Propriedades de uma JavaMail Session Fonte: Adaptado de: Using JavaMail API with Glassfish and Gmail (2010)
37 34 Depois de configurado esse serviço no servidor de aplicação é necessário criar uma classe EJB na aplicação, que será responsável por instanciar o recurso de criado no GlassFish e mandar o para o usuário. O Quadro 11 mostra o exemplo da classe que é responsável pelo envio de s. 3 public class EJB implements EJBRemote, Serializable{ 4 5 private static final long serialversionuid = 1L; private Session mailsession; 9 11 public void sendmessage(string , String assunto, String 12 mensagem) { 13 Message msg = new MimeMessage(mailSession); 14 try{ 15 msg.setsubject(assunto); 16 msg.setrecipient(recipienttype.to, new 17 InternetAddress( )); 18 msg.settext(mensagem); 19 Transport.send(msg); }catch(messagingexception me){ 22 me.printstacktrace(); 23 } 24 } 25 } Quadro 11 Classe responsável por fazer o envio de s A entidade estabelecimento, que representa o cadastro do usuário, possui um atributo chamado codigobloqueio. O código de bloqueio é criado no momento em que o usuário efetua o cadastro, através do método mostrado no Quadro public Long gerarnumerodesbloqueio(){ 2 String numero = ""; 3 for(int i=0;i<8;i++){ 4 numero+=new Long(Math.abs(new 5 Random().nextLong())).toString().charAt(0); 6 } 7 return new Long(numero); 8 } Quadro 12 Método responsável por gerar o código de bloqueio do cadastro
38 35 Após realizar o cadastro o usuário receberá um com um link que contém como parâmetros o código de bloqueio e o do próprio usuário. Acessando esse link o usuário será direcionado para a página de desbloqueio que receberá os parâmetros que foram passados na url. Com isso, basta o usuário avançar com o cadastro que terá a sua conta desbloqueada. O método que efetua o desbloqueio do cadastro é mostrado no Quadro public boolean desbloquearestabelecimento(long codigodedesbloqueio, 3 String ) throws Exception { 4 5 //Faz uma busca pelo estabelecimento através do 6 Query query = 7 em.createnamedquery("estabelecimento.buscarestabelecimentopor "); 8 query.setparameter(" ", ); 9 11 List<Estabelecimento> lista = query.getresultlist(); 12 if(lista==null lista.isempty()){ 13 return false; 14 } 15 Estabelecimento estabelecimento = lista.get(0); //Verifica se o codigo do desbloqueio confere if(estabelecimento.getcodigobloqueio().equals(codigodedesbloqueio)){ 20 //Desbloqueia o estabelecimento 21 estabelecimento.desbloquearestabelecimento(); 22 this.salvar(estabelecimento); 23 return true; 24 } 25 return false; 26 } Quadro 13 Método responsável por realizar o desbloqueio do cadastro Captcha Um outro requisito de segurança importante é impedir que programas automatizados não consigam realizar cadastros no sistema. Para impedir esse tipo de ação existe um mecanismo simples, porém muito eficaz que é conhecido como Captcha.
39 36 Captcha é um acrônimo para Completely Automated Public Turing Test to Tell Computers and Humans Apart, ou seja, um teste público totalmente automatizado para diferenciar humanos de computadores (LANDIM, 2009). De um modo geral, o Captcha serve como um recurso auxiliar para evitar spams ou mensagens disparadas por outros computadores ou robôs. A idéia é que as respostas dos testes que são feitos no Captcha sejam impossíveis de serem respondidas por um computador, permitindo assim que somente seres humanos tenham acesso a determinados conteúdos ou possam enviar informações (LANDIM, 2009). O Captcha utilizado na aplicação é fornecido pela biblioteca de componentes do Prime Faces. Esse Captcha, além de fazer um teste simples onde duas palavras mostradas devem ser digitadas corretamente, dá a opção para o usuário poder ouvir um outro teste que é feito especialmente para pessoas com deficiência visual. Isso é algo muito importante, pois a aplicação precisar ser acessível para todos. Para implementar o Captcha na aplicação é necessário primeiramente declarar o componente em uma página.xhtml. Essa ação é exemplificada no Quadro <!-- Captcha --> 2 <h:panelgroup id="captchagroup" styleclass="groups"> 3 <h:message for="captcha" styleclass="error- message" /> 4 <br /> 5 <span> 6 <p:captcha id="captcha" label="captcha" language="pt" theme="white" /> 7 </span> 8 </h:panelgroup> Quadro 14 Declarando o componente Captcha em uma página.xhtml Para o Captcha funcionar corretamente, existe também a necessidade de criar uma chave pública e privada para esse componente. Para isso, é necessário que seja feito um cadastro no serviço do Google chamado ReCaptcha. Com esse cadastro, será gerada uma chave pública e uma chave privada que serão utilizadas pelo sistema para garantir a segurança do mesmo. O Quadro 15 mostra como configurar essas chaves na aplicação dentro do arquivo web.xml.
40 37 1 <context-param> 2 <param-name>primefaces.public_captcha_key</param-name> 3 <param-value>6lcnicisaaaaah4uil6bcspcnxdjv189t6a2ia2-</param-value> 4 </context-param> 5 <context-param> 6 <param-name>primefaces.private_captcha_key</param-name> 7 <param-value>6lcnicisaaaaaa7kf4imf6qw3urfwqvurwjf8fy3</param-value> 8 </context-param> Quadro 15 Configuração das chaves pública e privada do Captcha Com essas configurações a página de cadastro da aplicação estará protegida contra ataques de programas automatizados. A Figura 7 mostra a página de cadastro com o Captcha implementado. Figura 7 Captcha na página de cadastro 3.5 OTIMIZANDO O DESEMPENHO DA APLICAÇÃO Não basta apenas deixar a aplicação segura. É necessário também configurar mecanismos que otimizem o seu desempenho para melhorar a satisfação do usuário e ter uma maior aceitação perante os mesmos. Existem algumas funcionalidades,
41 38 que podem ser configuradas no GlassFish que aumentam consideravelmente a performance da aplicação Compressão GZIP Gzip é a abreviação de GNU zip, um Software Livre de compressão sem perda de dados. A compressão por gzip é uma maneira bastante eficiente para otimizar o desempenho de um site. Consiste em enviar os códigos do site em formato comprimido, para que ocupem menos espaço e com isso trafeguem pela rede de forma mais rápida (ANTUNES, 2010). Para implementar esse protocolo os sistemas cliente e servidor trocam informações de controle entre si, nos cabeçalhos HTTP da solicitação e a das respostas. Primeiro o servidor verifica se o navegador tem suporte à compressão e caso tenha, o servidor irá comprimir os arquivos e então mandá-los para o browser. Caso o navegador não tenha suporte à compressão gzip os arquivos serão enviados normalmente sem serem comprimidos. Entretanto, atualmente todos os navegadores dão suporte à essa compressão (ANTUNES, 2010). O GlassFish permite ativar a compressão gzip mudando algumas configurações nos Network Listeners. A Figura 8 mostra as configurações feitas para ativar a compressão gzip. Essas configurações foram feitas no http-listener-1 que usa como porta padrão a Figura 8 Ativação da compressão gzip no GlassFish No campo Compressible Mime Types são informados os tipos de arquivos que serão comprimidos pelo servidor. O Quadro 16 mostra uma lista com os tipos mais comuns de mime types e a sua respectiva extensão.
42 39 Extensão.html.xml.js.jpeg.jpg.bmp.gif.png.avi.css Mime Type text/html text/xml application/x-javascript image/jpeg image/jpg image/bmp image/gif image/png video/avi text/css Quadro 16 Principais tipos de mime type Fonte: Adaptado de: Webmaster Toolkit (2011) Habilitando o cache de arquivos Outro recurso que pode ser habilitado no http-listener-1 é a ativação de cache para os arquivos da aplicação. Com isso os arquivos vão ser guardados no cache do navegador e serão carregados mais rapidamente, aumentando o desempenho da aplicação. A Figura 9 mostra as configurações para a ativação desse recurso. Figura 9 Habilitando o cache de arquivos
43 40 Para testar o impacto real dessas modificações na aplicação, foi utilizado o plugin Page Speed para o navegador Google Chrome. A Figura 10 mostra o resultado do teste do Page Speed na página inicial da aplicação antes de ativar os recursos de compressão e cache. É possível perceber que ele destaca em vermelho e amarelo os itens de Ativar compactação e Aproveitar cache do navegador. Figura 10 Teste do Page Speed sem os recursos de compressão e cache Realizando outro teste do Page Speed, agora com os recursos de compressão gzip e cache ativos, é possível perceber que houve um aumento significativo no desempenho da aplicação. A Figura 11 mostra o resultado desse teste. Figura 11 Teste do Page Speed com os recursos de compressão e cache ativos