Autentificacin y

Seguridad en
Aplicaciones
Web
Delegadas en el cliente y el servidor
Basados en estndares de Internet
Autentificacin Bsica HTTP
Autentificacin Digest HTTP
Autentificacin de cliente HTTPs
Basados en la especificacin de servlets
Autentificacin basada en formularios
Autentificacin controlada por programa
Hay que basarla en conexiones seguras con HTTPs



Parte del protocolo HTTP desde sus
comienzos.
Muy simple
Poco seguro
Cuando el navegador solicita un recurso (jsp,
por ejemplo), el servidor solicita usuario y
contrasea, que viajan encriptadas con
codificacin base 64 bits.
Se puede reforzar combinndola con
protocolo HTTPs, de forma que las peticiones
HTTP viajen encriptadas.

Incorporada en la versin 1.1 de la
especificacin del protocolo HTTP.
Algo ms complicada internamente que la
autentificacin bsica.
La codificacin va en base al timestamp
generado por el servidor en el momento de
la peticin -> Ms difcil de decodificar ->
Ms seguro.
No est totalmente difundida ni aceptada por
todos los navegadores y servidores.




Es el ms seguro de los disponibles hoy en
da.
Se basa en mecanismos de Clave Pblica
(PKI)
Requiere una clave generada por un
organismo de certificacin autorizado.
Hay un proceso complicado de
handshake que garantiza la conexin
segura.

La nica definida en la especificacin de
servlets.
Implementada por el contenedor Web.
No es segura por si sola, y es necesario
combinarla con HTTPs (SSL Secure Socket
Layer).
Permite controlar la apariencia de la pantalla
de login.
La pantalla de login es HTML estndar que
sigue un convenio para los nombres del os
campos de usuario y contrasea.



Todo lo tenemos que programar
La aplicacin coteja la contrasea contra su
propio sistema de control de usuarios
Hay que basarla en protocolos seguros de
comunicacin como HTTPs (SSL) para evitar
que nadie escuche la contrasea
interpretando los paquetes HTTP.
Mas tedioso de programar
Ventajas: No dependemos de la
autentificacin del entorno -> Ms portable.



Es necesario:
Configurar el server.xml de TOMCAT para que solicite
autentificacin basada en memoria (tomcat_users.xml).
Crear usuarios y perfiles en tomcat_users.xml
Configurar el WEB.xml para restringir el acceso a los
recursos a un determinado(s) perfil(es) de usuario.
El usuario se autentifica contra el servidor
mediante la ventana gris (no HTML)




En el server.xml:
<Realm className=
"org.apache.catalina.realm.MemoryRealm" />
En Tomcat_users.xml:
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="uniovi"/>
<user username="dflanvin" password="dflanvin"
roles="uniovi"/>
</tomcat-users>



En el web.xml:
<!--Autentificacin bsica. Tened en cuenta que los roles y
usuarios
con sus contraseas estn dados de alta en el servidor-->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Autentificacin del piloto Uniovi</realm-name>
</login-config>
<!--Damos de alta el role en la aplicacin-->
<security-role>
<role-name>uniovi</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>piloto</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>uniovi</role-name>
</auth-constraint>
</security-constraint>
<!--Aqu termina la seccin de autentificacin-->
Sobre la versin anterior:
1. Implementar login.jsp con un formulario con los
campos login y password para realizar el logueo
del usuario
2. Implementar un LoginServlet que chequee que
ambos son admin/admin, y en caso contrario,
retorne a la pgina de login. En caso de login
positivo, se mete un UsuarioBean en la sesin
bajo el nombre usuario con el id del usuario y
luego redirigimos.
3. Modificar la pgina destino para que antes de
nada, compruebe que el usuario est logueado.
En caso contrario, redirigimos a login.jsp
(Resuelto en piloto 1.0)
Problema: Estamos repitiendo cdigo en
todos los actions y jsps de la aplicacin:
comprobacin de que el usuario est en
sesin
Soluciones:
Extender las jsps de otra o jugar con los
includes.
Desde la versin 2.3 se servlets, incorporacin
un filtro HTTP.
Incorporados en la versin 2.3 de la
especificacin de servlets.
Interceptan la invocacin del servlet ANTES de
que sea invocado el propio servlet.
Permiten examinar y modificar la request
antes de que le llegue al servlet.
Permite modificar el response y redirigir, en
caso necesario, la peticin a otro recurso
distinto.
Ideales para el control de acceso de usuarios
autentificados.



Interfaz javax.servlet.Filter.
Tres mtodos:
void init(FilterConfig config) throws
ServletException: Invocado antes de que el filtro
entre en servicio. Permite configurar el filtro.
void destroy(): Invocado cuando el filtro dejar de
estar en servicio.
void doFilter(ServletRequest req, ServletResponse
res, FilterChain chain) throws IOException,
ServletException: Mtodo que implementar el
filtrado.


Servlet 1 Servlet 1 Servlet 1 Servlet 1
HTTP Filter
Sobre piloto 1.0, elaborar un filtro HTTP
que muestre un mensaje cada vez que es
solicitado un recurso de nuestro piloto.
Pasos:
Desarrollar la clase
com.dflanvin.presentacion.filter.LoginFilter
Importar las libreras necesarias
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;
import javax.servlet.ServletException;

public class LoginFilter implements Filter
{
private FilterConfig filterConfig;

public void doFilter (ServletRequest request,
ServletResponse response,
FilterChain chain)
{
System.out.println(Activado el filtrado de peticiones);
chain.doFilter (request, response);

System.out.println(Tras es doFilter.);

}

public void init(FilterConfig fliterConfig)
{
System.out.println(Inicializado el filtro);
}
public void destroy()
{
}
}

Y Modificar el WEB.XML para dar de alta los filtros
<!--Definicin de Filtros HTTP-->
<filter>
<filter-name>ControlAcceso</filter-name>
<filter-class>com.dflanvin.presentacion.filter.LoginFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ControlAcceso</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Resuelto en piloto 2.0
Consultar piloto 3.0