JEEBrasil -- O site da comunidade Java EE no Brasil

Informações

Tipo:	Artigo
Data de Publicação:	01/01/2004
Revisado em:	01/01/2004

Vote!

Currently 4,2/5 Stars.
1
2
3
4
5

Tags Relacionadas

j2ee seguranca

Comentários ( 7 )

Imprimir

Segurança no J2EE

por:

Gleydson Lima (gleydson@jeebrasil.com.br)

Introdução

O desenvolvimento de componentes deve ser feito utilizado o mínimo de dependência e especificidade. Ou seja, a idéia é poder reutilizar o componente em diversos contextos sem a necessidade de alteração de código.

A especificação J2EE permite usar um conjunto de regras de seguranças suportadas pelo servidor de aplicações. Basicamente existem dois tipos de segurança: as declarativas e programáticas. A segurança declarativa é aquela em que especificamos a configuração dos nossos serviços de segurança e o servidor de aplicações gerencia a segurança de acordo com o definido nos deployment descriptors. Na segurança programática o código de acesso aos recursos é feito em código.

No contexto de reutilização a segurança programática é bem mais benéfica, pois permite a alteração de regras de segurança apenas mudando os descritores do componente, não havendo a necessidade de alteração em código fonte e conseqüentemente re-compilação, remontagem do pacote etc.

A implementação do serviço de segurança no servidor de aplicação é um outro recurso extremamente importante no desenvolvimento de aplicações corporativas. O uso de segurança programática faz com que não nos preocupamos com a implementação das regras de segurança do componente deixando essa responsabilidade para um software bem testado e na maioria das vezes bem confiável, os servidores de aplicações.

Conceitos Importantes

Para o bom entendimento da segurança no J2EE é necessário que conheçamos alguns conceitos importantes. Os conceitos mais importantes são o de role, user, group e realm.

Role: Um role é um nível de permissão. Usuários podem ter roles diferentes e com acessos diferentes. Por exemplo, um sistema de gestão da empresa poderia ter os roles:
- Funcionário
- Gerente
- Diretor
- Fornecer
Cada ator interage com o sistema com níveis de permissões diferentes. Um Gerente e o Diretor têm acesso ao módulo de folha de pagamento, no entanto o Fornecedor e Funcionário não.

Um role representa, em níveis práticos, o papel que o usuário tem no domínio da empresa. Provavelmente, no domínio do negócio o funcionário não tem acesso a folha de pagamento da empresa. Isso deve se refletir no sistema.
User: Um usuário representa uma entidade com acesso ao sistema. O nível de acesso desse usuário vai depender do seu role.
O usuário claudio pode ter o role Gerente e o usuário marcos o role Funcionário.

Assim, no acesso ao sistema, o usuário claudio quando tentar acesso o módulo de folha de pagamento não será barrado pelo servidor de aplicações, permitindo assim que ele possa acessa-lo. Porém, se o usuário marcos tentar realizar a mesma operação o servidor de aplicações irá emitir um erro de segurança e não permitirá que se tenha acesso ao módulo.
Group: Um grupo é associado com um conjunto de roles e todo usuário que é membro do grupo automaticamente herda os roles associados.
Por exemplo, podemos criar um grupo denominado Gerencia. Os roles pertencentes ao grupo Gerencia serão Gerente e Diretor. Se colocarmos o usuário carlos pertencente ao grupo Gerencia, ele herdaria automaticamente todas as permissões do role Gerente e Diretor.
Realm: Um conjunto completo de usuários, roles e groups normalmente armazenados em algum banco de dados.
Existem vários tipos de Realm. Podermos guardar as informações de segurança em um servidor de diretórios LDAP ou NIS, em arquivos de configurações ou em um banco de dados.

Roles

Os roles são níveis de permissão que normalmente são associados com partes de URL que possuem acessos diferentes. Por exemplo, podemos dar acesso a URL http://www.empresa.com.br/folha-pagamento para somente usuários que possuam o role de diretor e http://www.empresa.com.br/contra-cheque para usuários que possuam o role de funcionário. Dessa forma os usuários que possuem o role funcionário não possui acesso à área de diretor.

Por exemplo, podemos definir esses roles no arquivo web.xml da aplicação, como mostra o exemplo abaixo:

<security-role>
        <description>Diretor da Empresa</description>
        <role-name>diretor</role-name>
</security-role>


<security-role>
        <description>Funcionário da Empresa</description>
        <role-name>funcionario</role-name>
</security-role>

Agora precisamos fazer um mapeamento de usuários com os roles, normalmente em nível de descritores isso é feito em deployment descriptores específicos do servidor, no caso do tomcat é o conf/tomcat-users.xml.

<?xml version='1.0'?>

<tomcat-users>
<user username='gleydson' password='abced' roles='diretor,funcionario'/>
<user username='jose' password='qwert'  roles='funcionario'/>
</tomcat-users>

Note que um usuário pode ter vários roles, dessa forma este usuário terá acesso à área de funcionário e diretor.

Referenciando um role existente

È possível adicionar links de roles, como é mostrado abaixo:

<security-role-ref>
        <role-name>empregado
        <role-link>funcionario
</security-role-ref>

Dessa forma o role empregado passa um link para o role funcionario.

Configurando o acesso a recursos Web

A configuração da segurança declarativa será dada no deployment descriptor (web.xml) da aplicação e basicamente por três tags XML:

<login-config>: Configura qual será o modo de requisitar a autenticação ao usuário e de qual realm o servidor de aplicações irá buscar informações.
<security-constraint>: Usada para configurar os acessos a um conjunto de recursos através de mapeamento de URL.
<security-role>: Representa um conjunto definido de grupos de realm.

Security Constraints

As security constraints determina quem é autorizado a acessar um conjunto de padrões de URL juntamente com seus métodos de acesso (POST ou GET). Caso você defina um security constraint para uma determinada URL o container só permitirá acesso a essa URL através de um usuário autenticado e com o role específico. Caso um outro usuário não autenticado tente acessar o conteúdo, o servidor irá tentar autenticar este usuário.

Autenticação de Usuários

Existem basicamente cinco tipos de autenticação de usuários como listado abaixo:

Nenhuma: Usuário não é autenticado.
HTTP Basic Authentication (<auth-method>BASIC</auth-method>): Este método de autenticação faz com que o browser solicite usuário e senha para autenticação através de um formulário proprietário do próprio browser.
Form-based Authentication (<auth-method>FORM</auth-method>): Este método permite ao usuário mostrar uma página JSP que será o formulário de autenticação como também uma página padrão de erros.
```
 
  <login-config>
    <auth-method>FORM</auth-method>
    <realm-name>default</realm-name>
    <form-login-config>
      <form-login-page>login.jsp</form-login-page>
      <form-error-page>error.jsp</form-error-page>
    </form-login-config>
  </login-config> 
```
Toda às vezes que os recursos configurados forem acessados e houver a necessidade de autenticação o formulário login.jsp será exibido.
Client-certificate authentication (<auth-method>CLIENT-CERT</auth-method>): Este é o método mais seguro de autenticação usando SSL e esquemas de troca de certificados para autenticação.

Digest Authentication(<auth-method>DIGEST</auth-method>): O método DIGEST é parecido com o BASIC e FORM, porém as informações de password são enviadas criptografadas através de algum algoritmo de hashing. Dessa forma a senha trafega criptografada mesmo em canais não seguros.

Exemplo de uma configuração de web.xml:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 
2.3//EN"  "http://java.sun.com./dtd/web-app_2_3.dtd">

...

<display-name>J2EEBrasilApp</display-name>
	<servlet>
		<servlet-name>index</servlet-name>
		<display-name>index</display-name>
		<jsp-file>/index.jsp</jsp-file>
	</servlet>

	<session-config>
		<session-timeout>30</session-timeout>
	</session-config>

	<!-- REGRAS DE SEGURANÇA -->

	<security-constraint>
		<web-resource-collection>
			<web-resource-name>WRCollection</web-resource-name>
			<url-pattern>/sistema/contra-cheque/</url-pattern>
			<http-method>GET</http-method>
		</web-resource-collection>
		
		<auth-constraint>
			<role-name>funcionario</role-name>
		</auth-constraint>

		<user-data-constraint>
			<transport-guarantee>NONE</transport-guarantee>
		</user-data-constraint>
	</security-constraint>

	<security-constraint>
		<web-resource-collection>
			<web-resource-name>WRCollection</web-resource-name>
			<url-pattern>/sistema/folha-pagamento/</url-pattern>
			<http-method>GET</http-method>
		</web-resource-collection>

		<auth-constraint>
			<role-name>diretor</role-name>
		</auth-constraint>

		<user-data-constraint>
			<transport-guarantee>NONE</transport-guarantee>
		</user-data-constraint>

	</security-constraint>

	<!-- MÉTODO DE LOGIN -->

	<login-config>
		<realm-name></realm-name>
		<auth-method>BASIC</auth-method>
	</login-config>

	<!-- ROLES DE SEGURANÇA -->
	<security-role>
		<role-name>diretor</role-name>
	</security-role>

	<security-role>
		<role-name>funcionario</role-name>
	</security-role>

Comentários (7)

Muito boa a explicação. Porem toda vez que for criado um usuário novo vai ser preciso colocalo no arquivo do Tomcat e isso é mo bacalho.: postado por Gabriela em 18/11/2006 às 23:21
gostaria de sabe onde eu posso encontra o programa forms para dos: postado por luciano em 02/12/2006 às 23:21
Para colocar um novo sem precisar criar tudo no Tomcat é só usar um banco de dados relacional conforme http://tomcat.apache.org/tomcat-4.1-doc/realm-howto.html . Configura-se o server.xml e o web.xml conforme está acima.: postado por Leandro em 22/01/2007 às 23:21
A Stefanini está com oportunidades para JAVA, J2EE, quem estiver dentro do perfil por favor encaminhar cv atualizado para este e.mail. Atenciosamente, Luciana Prudente Recrutadora Comercial.: postado por Luciana Prudente em 18/06/2007 às 23:21
Aproveitando o exemplo do contracheque q foi dado, estou desenvolvendo um site que contém um link Contracheque e estou utilizando a opção Basic Authentication. Como este site ficará disponível em um terminal para os funcionários, percebi que será necessário que a tela de autenticação apareça todas as vezes que se clicar no botão. Independente se o browser se mantiver aberto ou não, pois senão um segundo usuário visualizará o contracheque do primeiro, já que para o segundo a tela de autenticação não carrega. Vou ter que usar outra opção de autenticação? É possível aparecer a tela de autenticação sempre q o usuário clicar no link contracheque? Ou terei que desenvolver uma aplicação para forçar a autenticação?: postado por marcia em 04/07/2007 às 23:21
Foi uma ótima introdução. Estou com problemas para trabalhar com dois realm no jboss, uma app usa determinada tabela para pegar os usuários e outra uma segunda. É que minha aplicação faz login pelo CLIENT-CERT e não pelo email.: postado por Marcos Katsumi Kay em 05/10/2007 às 23:21
Muito bom. Obrigado: postado por Luiz Mendes em 24/07/2009 às 23:21

JEEBrasil

O site da comunidade Java EE no Brasil

Encontre