O básico sobre segurança em aplicações WEB Java usando JAAS

Como vocês já perceberam em postagens anteriores, o servlet é uma classe java que responde a requisições. O HttpServlet responde a requisições HTTP.
Servlets não tem um main, isso por que instalamos os mesmos em um servidor Java WEB(um contêiner) e ele invoca os métodos do Servlet pra gente. Mais do que isso! O conteiner controla o ciclo de vida e faz o tratamento das requisições HTTP, transformando elas em objetos Java que você pode usar em seu código.
Uma das maiores vantagens de delegarmos as coisas para o contêiner é programar menos e deixar ele fazer as coisas para a gente. Por exemplo, injeção de dependência, controle de transação e segurança podem ser delegadas para o contêiner sendo que você pode focar no seu código Java. Outro ponto é a flexibilidade da sua aplicação, podemos configurar as coisas no contêiner invés de termos que modificar o código da app.
Nesse artigo vamos mostrar como delegar a tarefa de login para o Wildfly em poucos passos, não iremos mostrar a fundo diversas coisas, mas futuramente voltaremos a esse tópico.

Nosso "alvo"

Lembra do "Olá Mundo com Servlet"? Criamos uma versão com segurança onde um acesso ao servlet irá requerer autenticação. Vamos ser bem diretos no assunto, então é interessante que você tenha o Ola Servlet na sua máquina e todas as configurações feitas para executar o mesmo. Se tiver dúvidas, volte à postagem anterior.

Na nossa aplicação a execução do Olá Mundo só será possível se o usuário fornecer credenciais corretas.

Adicionando segurança à aplicação

1) Use web.xml para declarar a segurança que quer na sua aplicação. Nessa etapa falamos os contextos que irão sofrer segurança e o tipo de segurança aplicada(como autenticação BASIC);
2) Declare o security domain usado nesse aplicação usando o jboss-web.xml, um arquivo que deve ficar no diretório WEB-INF do seu WAR. Vejam abaixo o conteúdo dos arquivos web.xml e jboss-web.xml:

As modificações na nossa aplicação são só essas. Veja que a aplicação não sabe se as credenciais de segurança virão de um banco de dados, LDAP, arquivo de texto, etc. De fato, essa é a ideia: delegar a segurança para o servidor de aplicação. No nosso caso estamos usando um pronto que traz os dados de usuários e roles de arquivos gerenciados pelo Wilfly, o other. Vamos falar agora como poderíamos utilizar outras formas de autenticação no Widlfly 8.2.

3) Um outro passo seria alterar o arquivo standalone.xml do Wildfly para declarar como será feito a segurança; Esse arquivo fica em {INSTALAÇÃO WILDFLY}/standalone/configuration

A segurança pode ser feita através dos login modules. E nessa postagem usamos o security domain other, os que irão buscar as credenciais e irão checar roles em um arquivo de texto! Poderíamos utilizar outros Login Modules para acessar banco de dados, LDAP, etc, veja os login modules disponíveis.

Usando o other (que na verdade é o security domain padrão), temos que adicionar usuários com o script add-user.sh(ou bat para os usuários do outro sistema) que fica em {INSTALAÇÃO WILDFLY}/bin. Veja abaixo como é feito esse processo de adicionar usuário com esse script no ApplicationRealm (que é o que devemos usar no nosso caso):

Após fazer isso, só podemos executar o servlet passando dados de usuário que configuramos com esse script, ou não estaremos autorizados. Lembrando que o other foi usado para teste, você pode configurar um security domain que poderá auxiliar você trazendo roles e usuários de um LDAP, banco de dados, etc...

Se você tiver a nossa aplicação de olá mundo e modificar ela seguindo os passos aqui, ao acessar a mesma você terá que entrar com usuário e senha que você adicionou usando o add-user.

Conclusão

Mostramos o básico sobre segurança de aplicações WEB no Wildfly e não abordamos autorização, só autenticação. Há, obviamente, muito a ser aprendido e muitos detalhes e dúvidas que irão surgir no momento que você for criar a sua aplicação, por esse motivo voltaremos a esse tópico futuramente!