Autenticação Servlet – Parte 01

Dentro da especificação Servlet existe uma parcela que compreende a segurança dos recursos acessados por cliente. Dentre estes recursos esta autenticação através de formulário, certificados digitais e ate mesmo por tela autenticação gerada pelo próprio browser.

Dividirei o conteúdo em algumas partes e logo que for terminando de compor estarei disponibilizando. Segue abaixo em negrito o conteúdo que terminei:

Parte 01: Os quatro mecanismo de autenticação

Parte 02: Implantando

Parte 01: Os quatro mecanismo de autenticação

A especificação Servlet define quatro mecanismos de autenticação de usuários.

  • HTTP Basic authentication
  • HTTP Digest authentication
  • HTTPS Client authentication
  • HTTP FORM-based authentication

HTTP Basic Authentication

Definido na especificação HTTP 1.1 é o mais simples e mais comum mecanismo usado para proteger recursos. Onde cada vez que um recurso protegido é solicitado é o browser retorna com uma tela solicitando nome de usuário e senha.

Em resumo os seguintes passos acontecem:

  • O browser/navegador envia uma requisição para um recurso protegido. Mas o browser não sabe que este recurso é protegido, ele apenas envia uma requisição normal HTTP e aguarda a resposta.

Exemplo: GET /servlet/YRossServlet HTTP/1.1

  • O servidor ao receber a solicitação observa que o recurso é protegido, e ao invés de enviar o recurso, uma mensagem contendo o “code de status” igual a 401 Unauthorized é retornada de volta para o cliente (browser). Nesta mensagem, uma linha de cabeçalho é adicionada para informar ao browser que uma autenticação básica é necessária para acessar o recurso. Este cabeçalho especifica o contexto em que a autenticação será valida. Este contexto é conhecido como “realm”. Ele ajuda a organizar a lista de acesso dentro do servidor em diferentes categorias.

Exemplo:

HTTP/1.1 401 Unauthorized
Server: Tomcat/5.0.25
WWW-Authenticate: Basic realm=”administracao”
Content-Length=500
Content-Type=text/html

<html>
… dados…
</html>

Onde:

WWW-Authenticate: Basic: especifica o tipo de autenticação como Basic

realm=”administracao”: especifica o contexto (realm)

  • O browser recebe esta resposta, abre uma caixa de diálogo perguntando pelo nome de usuário e senha.
  • Uma vez que usuário entrou com nome de usuário e senha, o browser reenvia a requisição e passa no cabeçalho o valor “Authorization” com as informações digitadas pelo cliente.

Exemplo:

GET /servlet/SalesServlet HTTP/1.1
Authorization: Basic am9objpqamo=

Onde:

O Authorization especifica o realm como Basic e o valor “am9objpqamo=” é composição do nome de usuário e senha no seguinte formato: nomeusuario:senha, encodado na base 64 (Base64 encoded).

  • Quando o servidor recebe a requisição, ela valida o nome de usuário e senha. Se eles são validos, ele envia o recurso, por outro lado, se as informações estão invalidas, o servidor envia a mesma mensagem 401 Unauthorized.
  • O browser mostra o recurso (ou a caixa de dialogo novamente, solicitando nome de usuário e senha).

Vantagens

  1. É muito fácil de usar.
  2. Todos os browsers suportam, por ser uma especificação do HTTP 1.1

Desvantagens

  1. Não é seguro porque o nome de usuário e senha não são encriptados.
  2. Não é possível customizar, modificar, o visual da caixa de diálogo que solicita nome de usuário e senha.

HTTP Digest Authentication

Segue os mesmos passos do HTTP Basic authentication, mas neste caso a senha (password) é enviada em formato encriptado. Este método torna mais seguro a autenticação.

Vantagens

  1. Um pouco mais seguro que HTTP Basic authentication, por ter a senha (password) encriptado.

Desvantagens

  1. É suportado apenas em alguns browsers, como em versões superiores do Internet Explore 5.
  2. Muitos “servlet container” não suportam, pois a especificação não obriga.

HTTPS Client Authentication

HTTPS é o HTTP sobre SSL (Secure Socket Layer).

SSL foi desenvolvido pela Netscape para assegurar a privacidade da transmissão de dados sensíveis sobre a internet. Neste mecanismo, a autenticação é feita quando uma conexão SSL e estabelecida entre o browser e o servidor. Todos os dados são transmitidos em formato encriptado utilizando criptografia de chave publica(public-key) entre o browser e o “servlet container”, fincando assim transparente para o desenvolvedor.

Vantagens

  1. É o sistema de autenticação mais seguro, entre os quatro tipos especificados.
  2. Todos os browsers comumente usados têm suporte.

Desvantagens

  1. É necessário um certificado de uma autoridade certificadora, como VeriSign, ou ICP-Brasil.
  2. É custosa a implementação e manutenção.

FORM-based Authentication

Este mecanismo é similar a autenticação básica (Basic Authentication). Entretanto, neste é utilizado um formulário  HTML para captura o nome usuário e senha (username/password). O desenvolvedor deve criar uma página HTML contendo o formulário, que permite a customização do visual.

O unico requerimento é que a ação do formulário seja j_security_check e que deve ter dois campos: j_username e i_password.

Vantagens

  1. É muito fácil de implementar
  2. Todos os browsers suportam
  3. É possível a customização da tela de autenticação.

Desvantagens

  1. Não é seguro, o nome de usuário e senha não são encriptados.
  2. Deve ser usado apenas quando uma sessão é mantida usando cookies ou HTTPS

Implantando

Em Breve…

Explore posts in the same categories: Certificações, JEE, Java, SCWCD

Tags: , , , , ,

You can comment below, or link to this permanent URL from your own site.

One Comment on “Autenticação Servlet – Parte 01”


  1. [...] Parte 01: Os quatro mecanismo de autenticação [...]


Comment: