21 March 2007

JAAS y SecurityFilter

La seguridad es uno de los aspectos a resolver con importancia en estos dias tal como nos dice Cobit y también diferentes ISO's, y por ello un punto importante dentro de cualquier proyecto.

La seguridad se centra sobre dos conceptos básicos: autenticación y autorización. Usuarios se autentican al sistema probando que son lo que dicen ser, por mientras la autorización permite/no-permite acceso a ciertas áreas de la aplicación.

La arquitectura J2EE tiene resuelto (y sus contenedores) este paradigma a través de Java Authentication and Authorization Service (JAAS), la cual es un conjunto de packages con servicios para autenticar y controlar de acceso de una manera centralizada (en un descriptor), conviviendo con el contenedor web que la aplicación este utilizando (Jakarta Tomcat, JBoss, otros).


Esta forma de seguridad puede ser administrada a base del contenedor (container-managed security) o de la aplicación (application-managed security).

1. Esta primera opción, de tener dependencia del contenedor, aumenta la complejidad de administración ya que hay que preocuparse de este contenedor en particular aparte de la aplicación como tal, quedando dividida y preocupándose de ambas. (Ejemplo especificar el repositorio donde se encuentra el real, nombre de usuario, password de roles, etc.).

2. La segunda forma es lograr que la aplicación posea toda la responsabilidad haciéndola más compleja de desarrollar y logrando que su escalabilidad queda segmentada a la solución hecha. La solución implementada en nuestro proyecto es una solución híbrida en la cual dejamos la responsabilidad de la seguridad a la aplicación (autenticación y autorización) a través de un robusto proyecto open source llamado SecurityFilter que genera filtros Servlet para su control. Se logra tener la flexibilidad de una seguridad de aplicación, logrando dejar independiente el contenedor (por ejemplo por su posible migración de arquitectura de conexión de base de datos).

Autenticación Form-Based + SecurityFilter

Los contenedores web J2EE ofrecen tres tipos de mecanismos de autenticación: basic, form-based, y autenticación mutua. La mayoría de las aplicaciones web usan el tipo de form-based ya que permite que la interfaz del usuario sea personalizable (HTML). La autorización es implementada por los contenedores a través de roles de seguridad definidos en el descriptor de la aplicación web (web.xml).

SecurityFilter usa la misma arquitectura que Form-Based donde se configura a través de descriptores en la aplicación.

Existe web.xml donde colocamos el uso del filtro de servlet en la aplicación y que realmente es nuestra forma de seguridad, esta se ve así:

<filter>
  <filter-name>Security Filter</filter-name>
  <filter-class>org.securityfilter.filter.SecurityFilter</filter-class>
  <init-param>
    <param-name>config</param-name>
    <param-value>/WEB-INF/securityfilter-config.xml</param-value>
    <description>Configuracion</description>
  </init-param>
  <init-param>
    <param-name>validate</param-name>
    <param-value>true</param-value>
    <description>Validar debe ser verdadero</description>
  </init-param>
</filter>


Con ello nos permite personalizar cuales son las páginas de ingreso y no-autorización a la aplicación (con sus URLs respectivas):

<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>/jsp/publico/Index.jsp</form-login-page>
    <form-error-page>/jsp/publico/errorauth.jsp</form-error-page>
    <form-default-page>/LoginCliente.do</form-default-page>
  </form-login-config>
</login-config>

Se pueden mencionar los siguientes Tags principales que pueden ser descritos en el web.xml

  • <login-config>: especifica el tipo de configuración de registro (login). Puede incluir los siguientes subelementos
    • <auth-method>: opcional
    • <realm-name>: opcional
    • <form-login-config>:opcional

  • <form-login-config>: Específica los recursos utilizados en el registro login basado en formularios. Debe contener los subelementos siguientes:

    <form-login-page> y <form-error-page> siendo los dos requeridos.

  • <form-login-page>: especifica el nombre de un recurso (html, página JSP, servlet) que solicita el nombre de usuario y la contraseña. Esta página debe cumplir los siguientes requisitos

    1. El formulario debe utilizar METHOD = “POST” y ACTION=”j_security_check”
    2. El campo de nombre de usuario debe denominarse j_username
    3. el campo de contraseña debe denominarse j_password.

  • <form-error-page>: Especifica el nombre de un recurso (HTML, JSP, servlet) a mostrar cuando el registro basado en el formulario no sea correcto.

  • <auth-constraint>: Especifica una lista de nombres de funciones (o roles) tratada colectivamente en un elemento <security-constraint>. Puede contener los siguientes subelementos <description> el cual es opcional y <role-name> (cero o más).

  • <role-name>: Un nombre utilizado para identificar una función o rol con el que un usuario autenticado se puede registrar. Es el mismo valor especificado en el método request.isUserInRole() para permitir la ejecución condicional de partes de un servlet a
    usuario con roles o funciones diferentes.
Por motivos de estructura similar a J2EE el formulario HTML tiene que tener la siguiente estructura de los campos j_username y j_password con el nombre de acción j_security_check como lo podemos ver en el ejemplo:

<form method="POST" action="j_security_check">
  <input type="text" name="j_username">
  <input type="password" name="j_password">
</form>

Esta forma de conexión usa codificación de base64, que puede exponer el nombre de usuario y clave a menos que sea con conexiones SSL.

Así los pasos que usamos son:
  1. Si el usuario no ha sido autenticado, le pide al usuario que de sus datos para tal acción recarga -a la página de ingreso (login) definida en el descriptor.

  2. Valida las credenciales del usuario contra la base de datos ya que es parte de nuestra aplicación.

  3. Determina si el usuario autenticado entonces está autorizado a ingresar al área solicitada según el descriptor.

Autorización

Una vez autenticado obtenemos el rol que posee y se verifica si puede asignar a los recursos solicitados, SecurityFilter tiene un archivo llamado securityfilter-config.xml el cual tiene centralizado todas las páginas que se puedan acceder según rol definidos en la aplicación (y también aparezcan en la base de datos, cual es nuestro repositorio).

De esta forma podemos administrar de manera fácil que rol tiene derecho de acceso a que Actions de Struts o JSP, según la lógica de negocio diseñada.

Ejemplo:

<security-constraint>
  <web-resource-collection>
  <web-resource-name>Pagina seguras Clientes</web-resource-name>
    <url-pattern>/jsp/cliente/*.jsp</url-pattern>
    <url-pattern>/RegistroObra.do*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>cliente</role-name>
  </auth-constraint>
</security-constraint>


En este ejemplo podemos ver como se está asignando acceso a los JSP y un Action en particular únicamente a los usuarios que posean rol de “cliente”:

Además SecurtyFilter nos permite aun utilizar los métodos getRemoteUser(), isUserInRole(), y getUserPrincipal() para generar dentro de la aplicación reglas de seguridad a nivel de código Java.

Ventajas
  • La aplicación no necesita tener implementado el mecanismo de autenticación, sólo configurar los descriptores.
  • Con SecurityFilter la idea es empaquetar la seguridad dentro de la aplicación web, incluyendo la administración de roles, permitiendo generar un .war que puede liberarse en cualquier contenedor sin necesidad de configurar nada extra.


Bibliografía

iBATIS - The Beauty of Simplicity

When I was involved in a project for a Strength of Materials Certification Laboratory for my University, the solution included open source frameworks as Struts as presentation tier. but I had a doubt of connection tier.

The good point is Data model, tables, data, exist already, SQL queries I was going to be help for a student of last year, even more I could use some and I needed a simple solution, so EJB is discard immediately, Hibernate sound good (I reckon is the Object related tool on web today, but I need something simple and clean) then I remember I heard iBATIS as a easy-fast productivity SQL Mapper framework.

iBATIS gives all what I need, centralized management, easy of implement writing down all the SQL queries I need, linking them in a ResultSet (and JavaBean) and another doing the JSP interface (actually the html:form tags).



Thus the code could be reduce a lot, not doing those JDBC statement (mention above), besides I made a simple Java code to help writing down SQL maps and JavaBean (well, later on I knew there is Perl tool that do this better with DDL from the database: http://alxeg.narod.ru/ibatis/index.html . However my tool worked parsing , so it can read the name of the fields and make the JavaBean and XML; (this reduce even more the coding).

Another parameter to consider was
iBATIS born mature :) because after sun shows Jpetstore with better performance than Microsoft and release the interesting framework layer including SQL Maps and DAO.

Finally, the
iBATIS web scene was mature enough to get support for any issue on it. Plus the development team is still working hard enough to get more update version, solving some unexpected issues (you never know and it’s better to have some backup).
iBATIS mapped framework according to ibatis.apache.org, it has two important features, SQL maps and DAO -the last one we are going only mention because mapping is our main issue-

SQL Maps makes development much easier, and the maintenance too.

The Architecture of
iBATIS is:

Centralized SQL Mappings inside XML files, this way is easy to maintenance, flexible , scability, fix problems. Every java programmer knows how tedious is to code many times JDBC connection, making the code larger, more complex to read and worse to maintain and scability.



figure 1, taken from http://ibatis.apache.org/

architecture of iBATIS










<-- figure 2 --> data model of the example: entities (client, application_form, application_form_detail).

Here we configure the database properties (too redundant? :P)
database.properties:
driver=org.firebirdsql.jdbc.FBDriver
url=jdbc:firebirdsql:localhost/3050:C:/development/database/SAMPLEDBS.GDB
username=administrator
password=development2006


This file contains all the XML with SQL Maps
sql-map-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sqlMapConfig
PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN"
"http://www.ibatis.com/dtd/sql-map-config-2.dtd">

<sqlMapConfig>

<properties resource="database.properties" />

<transactionManager type="JDBC">
<dataSource type="SIMPLE">
<property name="JDBC.Driver" value="${driver}"/>
<property name="JDBC.ConnectionURL" value="${url}"/>
<property name="JDBC.Username" value="${username}"/>
<property name="JDBC.Password" value="${password}"/>
</dataSource>
</transactionManager>

<sqlMap resource="TmpIndicesSQL.xml" />
<sqlMap resource="DetalleSolicitudSQL.xml" />

</sqlMapConfig>


An example of SQL Map, showing how to make ResultSet, INSERT, SELECT and UPDATE statement, with dynamic concatenation of condition in the statement (AND/OR in the WHERE).
DetalleSolicitudSQL.xml:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
"http://www.ibatis.com/dtd/sql-map-2.dtd">

<sqlMap namespace="DetalleSolicitudSQL">

<cacheModel id="detallesolicitud_cache" type="MEMORY" >
<flushInterval hours="24"/>
<flushOnExecute statement= "insertDetalleSolicitud" />
<property name="reference-type" value="WEAK" />
</cacheModel>

<resultMap id="detallesolicitud_result" class="cl.unab.dicemat.utils.facade.DetalleSolicitud">
<result property="detsol_descripcion" column="x_detsol_descripcion" />
<result property="detsol_cantidad" column="x_detsol_cantidad" />
<result property="ens_cod_tipo" column="x_ens_cod_tipo" />
<result property="solcer_id" column="x_solcer_id" />
</resultMap>

<statement id="insertDetalleSolicitud">
INSERT INTO detalle_solicitud ( detsol_descripcion, detsol_cantidad, ens_cod_tipo, solcer_id )
VALUES ( #detsol_descripcion#, #detsol_cantidad#, #ens_cod_tipo#, #solcer_id# )
</statement>

<statement id="viewDetalleSolicitud" resultMap="detallesolicitud_result" cacheModel="detallesolicitud_cache">
SELECT detsol_descripcion AS x_detsol_descripcion,
detsol_cantidad AS x_detsol_cantidad,
ens_cod_tipo AS x_ens_cod_tipo,
solcer_id AS x_solcer_id
FROM
detalle_solicitud
</statement>

</sqlMap>

with a select to get a autoincrement key for Firebird database (also there is commented examples for PostgreSQL, in (2) you can get more code to different engines). This features that iBATIS has implemented for most DB engines, but still aren't 100% solve in the current time, however I could solved doing another query, leaving atomized and thread-safe. (I can show the example with Firebird). The good thing was the flexibility iBATIS has to go through this problem.

IndiceSQL.xml:

<resultMap id="tmpindices_result" class="cl.unab.dicemat.utils.facade.TmpIndices">
<result property="tabla" column="x_tabla" />
<result property="obra_id" column="x_obra_id" />
</resultMap>

<!--obra_id y tabla hacen solo de nombres genericos -->

<statement id="viewTmpIndices" resultMap="tmpindices_result" cacheModel="tmpindices_cache">
SELECT gen_id(GEN_SOLICITUDCERTIFICADO, 1) as x_obra_id,
rdb$$relation_id as x_tabla
FROM
rdb$$database
</statement>

SolicitudCertificadoAction.java snippet
The simple method dao.insertSolicitudCertificado(solicitudCertificadoDTO); insert the data in the javabean. Using beanutils commons.

SolicitudCertificadoForm.java, dynaform can be used, however I prefer to use normal JavaBean thus I can maintain the kind of data (int, String, Date).


Conclusion:

We finally are in the last stages of the project doing QA, the SQL Mapping was a success, I saved a lot of time though this framework. Getting a simpler and cleaner code, the performance of the application.


Bibliography:

iBATIS Home- ibatis.apache.org
iBATIS Wiki- http://opensource.atlassian.com/confluence/oss/display/IBATIS/Home
iBATIS mailing-list

Blog Archive

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.