La primera vez que me engañes sera culpa tuya;la segunda vez sera mia.
Proverbio árabe

[Struts] - Control de Acceso

El problema del control de acceso dentro de una aplicación web es habitual en las aplicaciones web. Es muy habitual comprobar que existe un objeto usuario en sesión, es decir, que el usuario se ha identificado correctamente en la aplicación y la sesión no está caducada. Y también es habitual comprobar que el usuario tiene privilegios para acceder a determinadas zonas.

Existen varias soluciones ya implementadas y fácilmente personalizadas para no obligarnos a implementar una solución propia para este problema. 

Tomcat, una solución sencilla 

Una forma de resolver fácilmente este problema es como se ha visto en otro post anterior, "Control de acceso a una aplicación web", delegando en Tomcat la resolución de este problema. Esta solución es una buena primera aproximación para una aplicación simple, pero resulta en general poco práctica como solución profesional.

Roles en Struts 

El problema de la solución anterior es su mantenimiento. En general, tanto los usuarios como sus roles varían en el tiempo, y suelen ser mantenidos con los demás datos de los usuarios.

Struts nos ofrece una solución sencilla.

En el fichero struts-config.xml, uno de los atributos que podemos declarar en nuestros elementos action es roles, que contiene la lista de los roles permitidos para acceder a dicho action.

El control de acceso, es decir, verificar que el usuario posee un rol de la lista de roles permitidos, lo realiza el método processRoles de la clase del framework de Struts org.apache.struts.action.RequestProcessor. Si queremos realizar alguna comprobación más personalizada podemos extender esta clase y sobreescribir el método.

Para declarar en el struts-config.xml nuestra clase extendida como controlador para que se utilice en lugar de la clase habitual de struts. Si hemos llamado a nuestra clase com.lycka.util.CustomRequestProcessor:

<controller>
   <set-property property="processorClass"
   value="com.lycka.util.CustomRequestProcessor"/>
</controller>

Existe el usuario en sesión ? 

Si necesitamos algo más sencillo, como únicamente comprobar que existe un objeto usuario en sesión diferente de null para permitir continuar o redirigir a una pantalla de error, podemos añadir esta comprobación en el método processPreprocess de la misma clase org.apache.struts.action.RequestProcessor.

Enlaces

Extending Struts 

Lyckapedia 

Technorati Tags: , ,

4 Comentarios hasta el momento »

  1. paulina dijo

    11 de October del 2007 a las 7:44 pm

    Hola, esta bueno tu articulo, pero tengo una duda, yo estoy autenticando usando jaas en mi aplicacion y la restriccion de roles la hago simplemente con struts-menu; mi problema es que no se de que forma setear el rol de mi usuario en la aplicacion de forma que esta pueda reconocer este rol durante el resto de la sesion? si pudieras ayudarme seria genial.
    Saludos,
    Paulina

  2. yoyoooyoy dijo

    16 de October del 2007 a las 11:20 pm

    Encantado de que te guste el artículo paulina,

    acabo de llegar de viaje, mañana te contesto si puedo.

    ciao

  3. yoyoooyoy dijo

    17 de October del 2007 a las 1:05 pm

    Vale, aunque toy enfermito y con curro para aburrir, a ver si te sirve esta respuesta. No sé si te he entendido bien la pregunta, y no sé si te servirá.

    Echa un vistazo aquí, http://www.jaasbook.com/ sobre jaas, que tiene un ejemplo parecido.

    Los roles de los usuarios se suelen definir en un archivo (tipo tomcat-users.xml) o en una base de datos, como cualquier otro atributo de tu objeto usuario.

    Luego, el módulo de login de tu aplicación comprueba si tu login-passwords son correctos, y si lo son, se deja tu objeto Usuario en la sesión hasta que abandones la aplicación (tu modulo de logout deberá de eliminar ese objeto de sesión) o se caduque.

    Así, cada vez que quieras en la aplicación obtener un dato de tu usuario, como el nombre, el mail, o sus roles, puedes obtenerlo de la sesión.

  4. Lycka Bonita » Blog Archive » [Struts] - Realizar una acción común en todos los action dijo

    23 de February del 2008 a las 1:59 pm

    [...] con otras soluciones para implementar la política de seguridad requerida ya discutidas aquí. Otros ejemplos podría ser auditoria o validaciones [...]

Comentarios RSS · TrackBack URI

Dejanos tu Comentario

Nombre: (Requerido)

E-Mail: (Requerido)

Sitio WEB:

Comentario:

Comenta