Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML.
Java Livre
Segurança no J2EE
Parte 2: Desenvolvimento e Deployment no JBoss
Aprenda a utilizar as facilidades de autenticação e controle de acesso do J2EE para aplicações web e EJBs, com o servidor JBoss.
Fernando Lozano
Na edição anterior, apresentamos os conceitos relacionados à segurança declarativa do J2EE, seu uso em aplicações Web e configurações particulares para o deployment no Tomcat, além de vários estudos de caso sobre situações comuns, como a criação de uma caixa de login na pagina inicial. Nesta segunda parte, apresentamos as configurações particulares para o deployment no JBoss, permitindo a execução de todos os exemplos da primeira parte neste servidor, alem de mostrar o uso da segurança declarativa em EJBs.
A separação J2EE estabelece uma separação J2EE estabelece uma separação clara entre as responsabilidades do desenvolvedor de aplicações e as do fornecedor de servidores de aplicações. O objetivo é garantir que uma aplicação possa ser executada de forma inalterada em qualquer servidor aderente á especificação J2EE, mas ao mesmo tempo dar aos fornecedores de servidores total liberdade em suas implementações. Isso fomenta a competição e leva a produtos mais rápidos, seguros e escaláveis.
Por isso usar os recursos de segurança do J2EE e as facilidades de persistência de objetos ou conectividade a outros serviços de rede exige configurações particulares para cada servidor.
O quadro “Segurança declarativa no J2EE” faz em breve recapitulação dos conceitos essenciais, para quem não tenha lido a primeira parte possa acompanhar este artigo.
Sabemos que versões recentes do JBoss utilizam por default o Tomcat como container web (o Jetty era utilizado ate a serie 3.0x). Alguns são induzidos por isso a utilizar as configurações do Tomcat modificando o arquivo Server.xml. Mas não funciona. Fora o suporte básico a servelets e JSP, os demais serviços do Tomcat não são utilizados pelo JBoss. Assim, configurações de segurança feitas no Tomcat ou ficam sem efeito ou entram em conflito com configurações do JBoss.
Da mesma forma, configurações de datasources e de JNDI, alem de instalação de bibliotecas compartilhadas por varias aplicações e outras características de container Web, devem ser realizadas segunda as regras estabelecidas pelo JBoss, e não pelo Tomcat.(para uma introdução ao JBoss você pode consultar as Edições 2 e 5; configurações do JBoss relativas a banco de dados foram apresentadas nas edições 8, 14 e 15.)
O exemplo deste artigo foram testados no JBoss 4.0.1 mas devem funcionar com alterações mínimas em qualquer versão, desde a 3.2.4. Versões anteriores, pelo menos a partir da 3.0, utilizam basicamente as mesmas configurações de segurança, mais não rodarão os exemplos por não suportarem o JSP2. 0.
Na adaptação dos exemplos para outras versões do JBoss, observe também o elemento <!DOCTYPE> dos descritores não padrão, que geralmente referencia o numero de versão do servidor. É seguro utilizar o DOCTYPE de uma versão antiga com uma mais recente, pois é prevista a compatibilidade desde a versão 2.4.
Validação de senhas com o JBoss
Primeiramente, vamos ver como configurar o JBoss para executar o exemplo jm-segurança-j2-form, apresentado na primeira parte. A Figura 1 ilustra as páginas desta aplicação. Há uma página inicial pública e dois links que são restritos apenas AA usuários com o perfil “usuário” ou “administrador”, respectivamente. Quando o usuário tenta seguir por um desses links é apresentada a pagina de login da aplicação.
O JBoss utiliza a API JAAS (Java Authorization and Authntication Service) para seus recursos de segurança. Entretanto, o uso do JAAS é apenas um detalhe da implementação particular do JBoss. Não há contato entre o desenvolvedor J2EE e as classes dessa API, que ficam completamente encapsuladas dentro do mecanismo de segurança previsto pelas especificações de Servelets e EJB. A única exceção é na programação de clientes remotos, que veremos no final deste artigo.
Colocando de outra forma, apenas o administrador d um servidor JBoss, ou desenvolvedor que crie novos serviços para expandir o JBoss, tem que se preocupar com a API JAAS. O desenvolvedor de aplicação web, componentes EJB ou web services não ira utiliza - lá. No máximo, o desenvolvedor (ou administrador) terá que acrescentar a aplicação um descritos não padrão do JBoss, que informa qual o nome da política de aplicação (application-policy) a ser utilizada.
O JAAS foi apresentado na Edição 16.
Uma política de aplicação é baseada em um módulo de login (login-module), que especifica onde obter as informações de senha e roles de cada usuário. São fornecidas pelo JBoss várias alternativas de modulo de login, baseados em arquivos de propriedades, banco de dados relacionais e diretórios LDAP. Vamos iniciar pelo módulo baseado em arquivos, depois veremos a configuração que utiliza um banco de dados.
O descritor não padrão deve ser armazenado no arquivo WEB-INF/jboss-web.xml (ou seja, lado a lado com o descritor padrão web.xml), dentro do pacote war da aplicação, seja ele um pacote aberto ou fechado. As políticas de aplicação do servidor são armazenadas no arquivo conf/login-config.xml da sua configuração de execução do JBoss.
A Listagem 1 ilustra como vincular à aplicação a política chamada “arquivo”; a Listagem 2 apresenta as modificações feitas no login-conf.xml para ativar esta política são mostrados nas Listagem 3 e 4.
Caso se desejar que um mesmo usuário seja vinculado a vários roles, todos estas roles devem ser inseridos na mesma linha do arquivo de propriedade, separados por virgulas. Por exemplo:
lozano=administrador,usuário
Onde instalar os arquivos de propriedades? Esses arquivos são carregados como recursos, portanto podem estar em qualquer pasta ou pacote visível pelo classloader da aplicação, por exemplo, dentro de WEB-INF/classes. A Figura 2 ilustra como fica a estrutura de arquivos da aplicação de exemplo, destacando as modificações feitas em relação ao código publicado na primeira parte.
Você pode copiar a aplicação para a pasta deploy do JBoss (ou empacotar a aplicação num war e copiar este pacote para a pasta deploy – para detalhes sobre esse processo veja o Tira-Dúvida sobre pacotes J2EE nas Edições 9 e 10). Neste caso, manter o pacote aberto facilita a atualização dos arquivos de propriedades, pois permite mudar senhas e roles sem precisar fazer o redeploy da aplicação.
...
