JSF: Controle de Sessões e Controle de Acesso

Aplicações web são constituídas, normalmente, de recursos e funcionalidades públicos, acessíveis a toda pessoa em contato com a Internet, e outros protegidos por níveis específicos de acesso. É muito comum vermos, em portais pela web, áreas restritas para candidatos em treinamento, funcionários, professores, administradores de sistemas, exibidas apenas mediante o fornecimento de credenciais com nível de acesso compatível com aquele previamente cadastrado em sistemas de informação relacionados. Outro comportamento muito comum em sistemas web é a exibição de determinadas informações sobre as quais o leque de operações permitidas varia de acordo com o tipo de usuário. Para exemplificar, imagine um sistema hipotético de controle acadêmico: enquanto professores possuem um perfil que os permite digitar as notas de seus alunos, estes últimos possuem um perfil um pouco mais restrito, que só os dá acesso à visualização de suas próprias notas. Embora a informação (nota) seja visível para ambos os perfis de usuário (professores e alunos), o escopo de atuação sobre ela varia sensivelmente.

Há três características importantes no enredo acima:

· Determinadas operações, para serem apresentadas e utilizadas, exigem autenticação de usuários;

· As atividades de um usuário autenticado pertencem a um contexto particular de uso do sistema;

· Pode haver atividades, em um sistema, que só devem ser apresentadas a tipos específicos de usuário.

Todas elas serão abordadas ao longo deste artigo, na forma de um tutorial e uma aplicação tema. Para efeito de norteamento do leitor, trabalharemos com as premissas estabelecidas a seguir:

· À primeira característica da lista acima, será atribuído o termo “controle de acesso”;

· À segunda, atribuiremos os termos “sessão” e “controle de sessão”;

· Por fim, à terceira característica, atribuiremos o termo “controle de perfis de acesso”.

Quando iniciarmos o tutorial, mais adiante, tais premissas ajudarão na identificação dos conceitos a elas associados e seu respectivo tratamento dentro das tecnologias adotadas.

E já que falamos em tecnologia, vamos analisar os fatos sob esta ótica a partir de agora. O mercado nos oferece opções variadas para atingirmos um nível satisfatório de segurança em sistemas baseados na plataforma Java EE e também fora dela. Boa parte de todo o trabalho consiste na configuração de bibliotecas, frameworks e outros recursos/sistemas relacionados, restando bem pouco a se fazer em termos de implementação. Isto torna as coisas bem mais simples e ágeis, mas o fato é que nem sempre foi assim. Toda esta facilidade de hoje é possível principalmente devido a alguns marcos muito significativos, dos quais destacaremos dois:

· Lançamento do Java 5 com amplo suporte a anotações, tornando boa parte da configuração de sistemas, de standalone a web (passando inclusive por mobile), muito mais simples;

· Lançamento do Java EE 6, com destaque para a API de Servlets 3.0 e CDI, permitindo a configuração de listeners e filtros (e servlets também, naturalmente) a partir de anotações muito simples de compreender e utilizar.

Além desses episódios essenciais da história da plataforma Java, é importante destacarmos a evolução expressiva do framework Spring, especialmente do módulo Spring Security, com poderosos recursos para controle de acesso, filtros, redirecionamento, sessões, dentre outros. Trata-se de um módulo relativamente simples de se usar e muito eficaz dentro de seus propósitos, permitindo ao desenvolvedor incorporar em suas aplicações um alto grau de robustez e confiabilidade. Atualmente, este módulo é um dos mais maduros do Spring e tem sido aplicado em soluções de inúmeras empresas ao redor do mundo. Para mais informações sobre o Spring e, especificamente, o Spring Security, consulte a seção Links ao final do artigo.

No tutorial a seguir, veremos como desenvolver uma aplicação em Java para a Web usando apenas os recursos disponíveis na plataforma Java EE e, principalmente, na especificação JSF 2 e em sua implementação mais popular, o PrimeFaces. A motivação para a definição deste escopo é sugerir ao leitor uma reflexão acerca de uma prática de mercado muito comum nos dias de hoje, que classificaremos neste artigo como subutilização. Frameworks são a grande onda da programação orientada a componentes, mas a alta variedade de “peças” neste “jogo” tem trazido um efeito colateral preocupante: a combinação de muitos frameworks para atender uma necessidade que, muitas vezes, seria sanada apenas por um ou dois deles.

O profissional dos dias de hoje conhece bem pouco o material com que trabalha em seu dia a dia, e algumas combinações de tecnologias são frequentemente utilizadas meramente por terem sido, em algum momento, rotuladas no mercado como garantias absolutas e inquestionáveis de qualidade, disponibilidade, escalabilidade e segurança. Será mesmo? Será que, ao longo do tempo, a necessidade por agilidade não nos tem trazido certa pressa pelo resultado, gerando deficiências e fragilidades para as quais temos dado, erradamente, pouca atenção e importância?

Hoje observamos o Spring como padrão consolidado de mercado. Não que haja algum problema com este framework, embora seu uso possa ser até substituído, em alguns casos, com recursos que o próprio Java EE 6 passou a oferecer (como o já mencionado CDI, acrônimo para Context and Dependency Injection). Para integração entre sistemas, por exemplo, podemos fazer uso do Spring Integration, mas existem alternativas bem interessantes e muito poderosas igualmente fáceis de aprender e empregar, como o Apache Camel, da Fundação Apache (vide seção Links para referência a este projeto). A reflexão que estamos sugerindo para o leitor da Java Magazine, principalmente para aqueles que já trabalham com (ou se interessam por) desenvolvimento web, é: e se, um dia, Spring não fosse mais uma opção? Como as empresas e os profissionais reagiriam a um movimento como este?

A preocupação maior deste texto que segue é exatamente esta: trazer para o leitor uma proposta, de certa forma, minimalista, que explore em uma intensidade maior os recursos de uma especificação sólida como a Java EE, como alternativa para essas combinações mercadológicas frequentemente encontradas por aí. Estas combinações, normalmente, configuram um uso muito aquém do potencial que cada framework empregado possui, gerando normalmente um indesejável (e desnecessário) overhead com reflexos diretos no desempenho e na complexidade de sistemas, além de exigir, naturalmente, profissionais gabaritados em uma gama muito maior de tecnologias do que o realmente necessário para se colocar aplicações de qualidade em execução."