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 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
- É muito fácil de usar.
- Todos os browsers suportam, por ser uma especificação do HTTP 1.1
Desvantagens
- Não é seguro porque o nome de usuário e senha não são encriptados.
- 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
- Um pouco mais seguro que HTTP Basic authentication, por ter a senha (password) encriptado.
Desvantagens
- É suportado apenas em alguns browsers, como em versões superiores do Internet Explore 5.
- 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
- É o sistema de autenticação mais seguro, entre os quatro tipos especificados.
- Todos os browsers comumente usados têm suporte.
Desvantagens
- É necessário um certificado de uma autoridade certificadora, como VeriSign, ou ICP-Brasil.
- É 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
- É muito fácil de implementar
- Todos os browsers suportam
- É possível a customização da tela de autenticação.
Desvantagens
- Não é seguro, o nome de usuário e senha não são encriptados.
- Deve ser usado apenas quando uma sessão é mantida usando cookies ou HTTPS
Implantando
Em Breve…
Tags: Authentication, HTTP Basic authentication, HTTP Digest authentication, HTTP FORM-based authentication, HTTPS Client authentication, Servlet
You can comment below, or link to this permanent URL from your own site.
20/08/2009 at 22:08
[...] Parte 01: Os quatro mecanismo de autenticação [...]