La explotación de los fallos de seguridad en las arquitecturas de software no siempre viene determinada por las vulnerabilidades descubiertas en las tecnologías usadas para construir el sistema, sino también por el deficiente diseño por parte de analistas y/o malas prácticas y anti patrones usados por los propios desarrolladores. Es común encontrar programadores que todavía usan las tecnologías obsoletas, se sienten cómodos incrustando código Java dentro de las páginas JSP, o están usando operadores del propio lenguaje para concatenar los parámetros de las consultas / sentencias SQL y un largo etcétera de disparates. Incluso en las arquitecturas en capas, la ausencia de patrones de diseño tiene como resultado un sistema altamente acoplado y difícilmente escalable. Además, la capa de negocio empieza a delegar las responsabilidades impropias, como el manejo de transacciones, auditoría, seguridad – concerns transversales que se deberían encapsular y aplicar de forma transparente.

Las consecuencias de todo esto a largo plazo pueden llegar a ser realmente caóticas. El mantenimiento y la implementación de nuevos requisitos funcionales cada vez se vuelve más complicado, haciendo que el número de fallos y vulnerabilidades para comprometer el sistema se multiplique. Hacer software de gran calidad y aplicar la integración continua, desde luego no es tarea trivial, aun menos, hoy en día, cuando los usuarios cada vez son más exigentes y piden aplicaciones más potentes, rápidas y flexibles.

Después de un considerable parón volvemos con un post cargado de temas interesantes sobre nuestro framework de seguridad favorito. En la última entrada aprendimos los conceptos básicos de Spring Security – protección de las URLs, autenticación básica, securización de métodos de la capa de negocio, etc. Pero para desplegar la aplicación en un entorno de producción, todavía nos quedan una serie de puntos importantes por tratar.

Uno de los más cruciales es el almacenamiento seguro de las credenciales de usuarios. Actualmente el proceso de autenticación utiliza el gestor que almacena los datos en memoria (org.springframework.security.core.userdetails.memory.InMemoryDaoImpl) para validar las credenciales proporcionadas por el usuario. Ya vimos en su momento que era bastante trivial de configurar, pero al mismo tiempo sus desventajas nos impiden utilizarlo en escenarios más allá de una simple prueba de concepto. Debido a que la información se aloja dentro de la JVM, en cuanto se reinicie el servidor de aplicaciones se perderán todos los cambios que los usuarios podrían haber efectuado sobre sus cuentas. Al definir los usuarios y los roles como metadatos de la propia configuración de contexto de Spring Security, las contraseñas también se definen en texto plano.

Como ya adelantamos en la entrada anterior, el proceso de aprendizaje y demostración de Spring Security lo llevaremos a cabo construyendo una aplicación web. Para ser más precisos, se trata de una aplicación web colaborativa que permitirá a los usuarios organizar, crear y compartir sus colecciones musicales (álbumes, discos, artistas). Además, podrán planificar y tener noticias actualizadas de los últimos eventos musicales, crear anuncios de trabajo relacionados con la música, listas de reproducción, etc. Actualmente, solo una pequeña parte de la funcionalidad anteriormente dicha está implementada, pero que iremos completando en las próximas entradas. En la siguiente imagen se aprecia la página principal de nuestra aplicación.

Se pueden diferenciar claramente tres zonas:

Esta va ser la primera de las n entradas que vamos a dedicar a Spring Security. Para los que todavía no lo conocen, Spring Security es uno de los framework de seguridad J2EE más populares y completos usado por parte de instituciones, empresas e universidades muy importantes. Con Spring Security es bastante trivial incorporar la infraestructura básica de seguridad en una aplicación ya implementada sin necesidad de escribir ni una línea de código gracias a su naturaleza no invasiva. Además, posee componentes ya implementados que permiten la integración con sistemas externos con mucha facilidad. Inicialmente fue basado en el proyecto Acegi Security, que con los años se fue convirtiendo en un producto robusto y maduro, actualmente miembro de la familia de productos Spring. Debido a que muchos de los conceptos como la inyección de dependencias y programación orientada a aspectos los hereda de Spring, es aconsejable que tengamos nociones básicas de las mismas.

La seguridad de la aplicación en sí se considera como un requisito transversal, y por lo tanto se puede encapsular en forma de aspecto y más tarde aplicarse de forma declarativa en cualquier punto de nuestra aplicación. Spring Security ofrece módulos que aíslan ese tipo de lógica, permitiendo además que la aplicación tenga una arquitectura robusta, limpia y débilmente acoplada.