Isso acontece muito quando o âmbito é segurança. Qual cliente ou usuário não se preocupa com segurança? Ao menos um controle de acesso com autenticação através de usuário e senha eles sempre exigem. E qualquer desenvolvedor que se preze se preocupa com isso.

Quando pensamos em segurança em aplicações Java temos que conhecer bem como funciona a arquitetura de segurança da plataforma Java, que é bem completa a útil. A divisão se dá em três “áreas” distintas, que são: JCA - Java Cryptography Architecture – Define classes e interfaces que são responsáveis por trabalhar com criptografia e descriptografia de dados e informações; JSSE - Java Secure Socket Extension – Usa a JCA para criar conexões seguras para troca de dados e informações; e JAAS - Java Authentication and Authorization Service – Responsável por autenticação e autorização nas aplicações Java. Neste post vou abordar somente um pouco do JSSE, para saber mais sobre JAAS veja no arquivo do blog.

O SSL (Secure Socket Layer) e o TLS (Transport Layer Security) são protocolos criptográficos usados para garantir a comunicação segura entre serviços de internet. Não vou entrar em detalhes sobre os protocolos e nem nas suas diferenças, para maiores informações sugiro esta leitura.

A necessidade fundamental de uma implementação com SSL é garantir a privacidade e integridade dos dados trafegados entre as aplicações que estão se comunicando. E isso é realizado através da autenticação das aplicações e da utilização de algoritmo criptográfico nos dados que estão sendo trafegados.

Dizer isso é meio bonitinho mas ninguém consegue compreender como isso ocorre de verdade, o que acontece por “por baixo dos panos”. Vamos imaginar um cliente utilizando um browser qualquer para acessar uma aplicação instalada num servidor JBoss, com certificado SSL implantado. Quando a comunicação entre eles é iniciada o servidor envia uma chave pública ao browser, que usa esta chave para criar uma chave privada temporária que é enviada de volta ao servidor. Desta forma as duas partes, servidor e browser, usarão estas chaves para estabelecer uma comunicação segura. Para saber mais sobre chaves públicas, privadas, criptografia simétrica e assimétrica veja a minha apresentação sobre certificação digital.

Vamos então por a mão na massa e configurar a aplicação.

Criando as chaves

Usaremos o keytool para criar um keystore e nele armazenar as chaves.

Detalhamento do comando:

• keytool: comando
• -genkey: parrâmetro para criação das chaves
• -keystore: indica o caminho/nome do keystore (jeve.keystore)
• -storepass: indica a senha do keystore (jevepass)
• -keypass: indica a senha da chave (jevepass)
• -keyalg: indica o algoritmo de criptografia utilizado (RSA)
• -alias: indica o nome da chave a ser criada dentro do keystore (jeve_key)
• -validity: Validade do certificado em dias (3650)
• -dname “[...]“: Informações do certificado (CN = nome comum, OU = unidade organizacional (departamento, divisão), O = nome da organização, L = nome da localidade (cidade), S = estado, C = código do país)

Próximos passos, informar ao JBoss/Tomcat onde está o keystore e qual chave usar.

Instalando as chaves

Basicamente temos que copiar o arquivo do keystore, gerado no passo anterior, para o JBoss. O ideal seria em:

Configurando o JBoss ou o Tomcat

Trabalharemos agora no arquivo server.xml para configurar qual keystore usar. Este é um arquivo de configuração do Tomcat.

Se você estiver usando JBoss:

Se estiver usando Tomcat:

Procure por um comentário semelhante a este:

Haverá um trecho do arquivo comentado logo abaixo, vamos retirar os comentários e ativar este trecho de código. Ajustando as propriedades adequadas chegaremos em algo próximo disso:

Os pontos mais importantes são: port, keystoreFile e keystorePass, que são responsáveis por, respectivamente, definir a porta para utilização do SSL, qual o arquivo contém as chaves e qual a senha do arquivo que contém as chaves.

Neste ponto já conseguimos utilizar a aplicação através do protocolo HTTPS, basta acessar:

Configurando a aplicação

Até aqui a aplicação está disponível tanto através de HTTP quando através de HTTPS. Em algumas situações isso é desejado, em outras não. Existem casos onde precisaremos que algumas partes ou módulos da aplicação só funcionem com HTTPS e outras situações que toda a aplicação responda somente sob HTTPS, e ambas são possíveis de serem atendidas, veremos.

Inserindo este trecho no seu web.xml nós faremos com que a aplicação inteira responda apenas sob protocolo HTTPS.

Importando um certificado válido

Tudo foi feito utilizando um certificado fictício e poderá correr assim durante o desenvolvimento, não há problema algum. Mas em produção este certificado terá o mesmo valor que uma nota de um cruzado novo. Então você, ou sua empresa, farão a aquisição de um certificado válido através de um autoridade certificadora e, quando isso ocorrer importaremos o certificado válido para nosso keystore, utilizando a mesma ferramenta que usamos para criar o certificado anterior (keytool) vejamos:

E pronto, certificado válido importado e comunicação segura garantida.

Desta vez a aplicação está no meu github, junto com a aplicação do primeiro post sobre JAAS. São elas:

• project-to-learn-jaas
• project-to-learn-jaas-complete

As aplicações possuem um README e alguma explicação, qualquer dúvida fiquem a vontade para lançar perguntas nos comentários, as duas aplicações foram feitas de forma a simplificar o máximo possível a utilização e configuração dos recursos de JAAS.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

• Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
• Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

A infra-estrutura (servidor e banco de dados)

O ponto chave para a configuração do JDBC Realm é o banco de dados (tabelas de usuário e grupos). Criaremos o schema com o SQL a seguir. Basicamente são apenas duas tabelas: usertable e grouptable.

A configuração do schema no realm será feita adiante e este exemplo está simples desta forma apenas para ficar o mais claro possível na configuração do realm. Certamente no seu caso você já terá suas tabelas de usuários e grupos e para usá-los basta fazer a configuração do realm de acordo com a sua realidade, alterando os valores das propriedades de configuração.

E agora vamos inserir alguns usuários e grupos para os testes, conforme o SQL abaixo. Os usuários serão: user, guest e admin e os grupos serão: users, e admins. Reparem que os grupos estão no plural, enquanto os usuários estão no singular. Este é um importante detalhe, a seguir, na configuração das roles usaremos os grupos para aplicar as regras e não os usuários.

Com o banco de dados pronto ainda precisamos de um passo antes do realm, precisaremos criar agora o Connection Pool e o DataSource para este banco de dados. O JNDI Name deste DataSource será usado na criação do realm, portanto, este passo é essencial para o funcionamento do exemplo. Entretanto, como o foco aqui não é a criação do DataSource, darei apenas o JNDI Name conforme usei no exemplo: learn-jaas-jdbc.

Agora só precisamos criar o realm, o nome usado para ele será learn-jaas-realm. No console do glassfish vamos em: Configuration >> Securiy >> Realm >> New. As propriedades deverão ser preenchidas de acordo com a imagem e a tabela abaixo (se o seu schema for diferente é só ajustar os valores):

Propriedade	Valor
jaas-context	jdbcRealm
datasource-jndi	learn-jaas-jdbc
user-table	usertable
user-name-column	userid
password-column	password
group-table	grouptable
group-name-column	groupid
digest-algorithm	none

A aplicação

Com a infra-estrutura necessária criada e funcionando, partiremos para a aplicação. Este será um ponto bem simples, a aplicação não terá nada além de 4 páginas JSP, web.xml e sun-web.xml. No Eclipse, criaremos um Dynamic Web Project usando o glassfish como servidor (JavaEE 5). As páginas citadas anteriormente ficarão dispostas conforme o projeto abaixo:

Em cada página index.jsp dos diretórios admin, public e users há um dizer assim: “Welcome Admin!”; “Welcome Guest!”; “Welcome User!”; respectivamente. E em /index.jsp há apenas os links para as demais páginas. Estes diretórios serão protegidos posteriormente.

O próximo passo consiste na criação das roles em nossa aplicação. Este costuma ser o ponto onde os iniciantes se confundem muito, por isso houve aquela distinção entre os nomes dos usuários e os grupos anteriormente. A criação das roles é livre, podemos criá-las como bem entendermos, o único ponto de atenção aqui é que a role é associada ao grupo, ou seja, uma role será aplicada para todos os usuários de um determinado grupo.

Então, em WEB-INF/sun-web.xml criaremos as roles associadas com os seus respectivos grupos:

As roles foram criadas com o sufixo -role apenas para ficar bem claro que são roles e não usuários ou grupos. Vejam que as roles estão associadas aos grupos e não aos usuários.

Este é um momento onde aplicaremos as regras hierárquicas e organizacionais da empresa, repare que o grupo admins aparece em todas as roles, afinal de contas, não queremos barrar ao administrador do sistema o acesso às páginas públicas ou de usuários, certo?

Próximo passo: Configuração do web.xml! A configuração da autenticação em si não passa de 4 linhas de xml, informaremos o tipo (método) de autenticação (pode ser none, basic, form e digest/certificate) e qual o nome do realm associado:

O que precisaremos agora é, com base nas roles, criar as regras de acesso na aplicação. Elas podem ser feitas de várias formas e como podemos usar URL Pattern para definir onde a regra será aplicada, faremos isso por diretórios, combinando os diretórios com as roles (admin, user e guest):

Repare que o código ficou grande, mas é muito repetitivo. Os pontos de atenção são o elemento url-pattern, onde é gerada a regra para onde as restrições serão aplicadas e, principalmente, o elemento role-name, onde definimos qual a role está associada com aquela regra. Mais uma vez repare que a regra de acesso é associada à role, já a role, por sua vez está associada com um grupo, que por sua vez está associado com um usuário.

Agora é só fazer o deploy e executar o projeto. Lembre-se das senhas (ou consulte no banco de dados) e faça o teste de acesso em cada página.

Para facilitar disponibilizei o projeto para download, basta clicar aqui. (por algum motivo alheio a minha compreensão o wordpress não deixou o nome do arquivo igual ao original, então, baste colocar um ponto antes do ‘tar’, deve ficar project-to-learn-jass.tar.gz)

Não, não quero colocar aqui o projeto e o link para o site pois não quero que esse post soe como uma crítica direto ao projeto, pois não é, é apenas uma crítica a forma em que uma questão em particular foi encarada, o que não tira os méritos do projeto.

IMHO, o problema foi o modo com que isso foi exposto e, até de certa forma, usado como motivo para justificar a adoção ao Ajax. No site do projeto existem claramente duas seções: Ajax e Não Utiliza Applets. A categoria Ajax é simples e mostra algumas vantagens de se utilizar Ajax na apresentação de aplicações Web. Já a categoria “Não Utiliza Applets” possui uma série de divagações das quais não concordei muito, e vou dizer o porque.

Começando:

Applets … …. além de serem mais lentos e inseguros…

Lentos eu até concordo quando comparados com utilitários bem escritos com JavaScript, mas isso não quer dizer que sempre será mais lento, não é difícil escorregar e perder a linha gerando na aplicação vários (ou até dezenas) Mega Bytes de JavaScript que serão tão lentos quanto um applet para carregar e poderão sacrificar o cliente como qualquer aplicação desktop repleta de memory leaks (quem nunca viu o Firefox sugando seus ~400Mb++ de memória?).

E a segurança, a não ser que o cliente esteja utilizando uma versão antiga da JVM (cujos bug já são conhecidos e possuem correção, geralmente em versões mais novas) eu concordo que possa haver problemas com segurança, mas ainda não concordo que a segurança de um applet seja inferior à de algum componente escrito em JavaScript. Podemos começar falando de vulnerabilidade ao cliente, com o applet, ou o cilente tem a JVM ou não tem, portanto, ou o applet irá funcionar ou não irá, já com o JavaScript, o controle de funcionar ou não, não é como um ON/OFF, o usuário tem diversas formas de bloquear e desbloquear determinadas operações, sem contar as formas existentes de interferir no fluxo normal de processamento do JavaScript, com o GraseMonkey, por exemplo, é fácil escrever códigos que se integram (inicialmente à apresentação) ao código JavaScript de qualquer página. Sem contar as possíveis formas de se utilizar de XSS para explorar falhas no DOM, HTML/Scripts injection, etc.

Em relação ao Javascript, os applets são mais lentos de processar alem de possuir espaço muito delimitado na página onde se executam

Essa parte de integração com os demais objetos da página realmente é um ponto fraco, muito fraco, quando utilizamos applets. Já a questão de velocidade de processamento, é fácil confundir o tempo de processamento gasto numa determinada funcionalidade com a quantidade de operações que cada funcionalidade realmente executa, mas como eu nunca fiz esse tipo de teste – de escrever um applet e um javascript que façam a mesma coisa – não irei muito além, apesar de não acreditar que possam haver diferenças tão grandes, afinal, tudo é executado no cliente, com os mesmos recursos.

todos os recursos são feitos sem a utilização de Applets (com eufemismo – isso não tem no site :D), os sistemas são baseados principalmente no AJAX, o que garante velocidade e segurança, além de que não é necessária a instalação da JVM na máquina do cliente

Pois é, antes que arremessem as pedras, não estou aqui defendendo o uso de applets frente a componentes Ajax, muito pelo contrário, eu já trabalhei bastante com applets e sei o quanto é chato, em todos os aspectos, e também já trabalhei, trabalho e pretendo trabalhar por um bom tempo com componentes Ajax bem escritos, a razão pela qual escrevi este post foi para, de certa forma, criticar o modo com que foi exposto o motivo para usar Ajax, não acho que seja necessário dizer: “- Uso Ajax pois Applets são lentos, inseguros, gordos e feios.”; afinal de contas, não é bem assim.