Ola,
Com relacao a verificacao de credenciais, de uma olhada nos Patterns JEE Front Controller e Intercepting Filter, que podem ser aplicados
perfeitamente a essa situacao. Eles podem ser utilizados para filtrar todos os requests e tomar uma decisao com relacao aos mesmos.
Solucao simples, elegante e modular.
Com relacao a questao do desempenho, o fato de armazenar as credenciais do usuario (seja um ID, seja um objeto, etc) nao tem reais impactos
em performance, a menos que voce faca agregacoes desnecessarias aos objetos na sessao, portanto, mantenha na sessao apenas o que realmente
for necessario.
Com relacao a questao de seguranca, suponha que um hacker consiga o ID de sessao de um usuario. Isso eh relativamente simples de obter,
basta anexar um HTTP sniffer num host e procurar pelo header JSESSIONID. OK. Ainda sim, ele teria que utilizar esse ID de sessao
para obter informacoes diretamente do objeto HttpSession no server, o que nao seria trivial. Contudo, se ele conhecer o sistema em uso, ele
poderia por exemplo construir um HTTP Request manualmente e submeter ao Server com uma action como parameter solicitando alguma
acao. Via de regra, sempre que se tratar de informacoes confidenciais utilize uma camada SSL para os protocolos de aplicacao, no caso, o HTTP,
isso resolve completamente os problemas acima, pois nao teria como o hacker obter o ID de sessao e dessa forma se passar por um usuario
autenticado. Por exemplo, a maioria dos sites de e-commerce utiliza HTTPS somente no instante de login (para criptografar as informacoes
de usuario, senha, etc) e no momento do checkout, quando o usuario insere informacoes confidenciais de cartao de credito, nome, endereco, etc.
Se um hacker utiliza a estrategia acima durante a sessao, o maximo que ele ira conseguir seria obter informacoes do carrinho de compras. Se o
seu site precisar trafegar informacao confidencial durante toda a sessao, entao voce ira precisar utilizar uma camada SSL (por exemplo, sites bancarios).
[ ]'s
