SCWCD - Seguridad en aplicaciones Web

Uno de los tópicos que se debe estudiar para la certificación SCWCD (Sun Certified Web Component Developer) son los mecanismos de seguridad en las aplicaciones Web.

Mecanismos de seguridad

La seguridad en los servlets se reduce a cuatro conceptos principales:

• authentication: El proceso de autenticación es el encargado de determinar que el interesado en acceder los recursos es realmente quien dice que es. Lo más común es hacer que el usuario o la aplicación envié un password que lo identifica.

• authorization: Es el proceso por el cual se restringe el acceso a ciertos recursos a un conjunto de clientes. En realidad, lo que se define es un conjunto de roles que pueden acceder a ciertos recursos y se asocia cada usuario a uno o más roles.

• data integrity: Es el proceso que asegura que los datos que se reciben (tanto el cliente como el servidor) no han sido corrompidos. Generalmente se usan algoritmos de encriptación para lograr esto.

• confidentiality: Es el proceso que intenta asegurar que solamente los clientes autorizados reciban la información. La manera de lograr esto puede ser a través del uso de claves públicas/privadas.

Tipos de autentificación definidos

La especificación de servlet ofrece cuatro tipos de autentificación:

• BASIC: Este es el método más simple, pero el más inseguro. Cuando usamos este tipo de autenticación, se abre una ventana en el browser del cliente para que este ingrese el usuario y el password. El password se envía al servidor codificado en Base64.

• FORM: Este método es similar a BASIC, pero utiliza un formulario provisto por el programador. Este formulario tiene que cumplir los siguientes requisitos:

1. El atributo “action” debe ser “j_security_check”
2. El casillero de ingreso del usuario debe llamarse “j_username”
3. El casillero de ingreso del password debe llamarse “j_password”
   

<form method="post" action="j_security_check"><br /> Usuario: <input type="text" name="j_username"><br /> Password: <input type="text" name="j_password"><br /></form>

• CLIENT-CERT: En este método se usan certificados digitales. El browser debe tener instalado el certificado para que la comunicación se pueda establecer.

• DIGEST: La autenticación también es hecha utilizando usuario y password, pero el password es enviado encriptado de una forma mucho más segura (por ejemplo, utilizando HTTPS client authentication).

Autorización

El primero paso es definir los roles que se encontraran definidos dentro de nuestro sistema. Para el caso de Tomcat, estos se definen en el archivo tomcat-users.xml. Dentro de este archivo, cada usuario tiene asignado un usuario y password; y puede estar asociado a uno o más roles.

<br /><tomcat-users><br /> <role rolename="”Admin”/"><br /> <role rolename="”Member”/"><br /> <role rolename="”Guest”/"><br /> <user username="”jose”" password="”duke”" roles="”Admin,"><br /></tomcat-users><br />

El siguiente paso es relacionar los roles definidos en el archivo tomcat-users.xml, con los roles a utilizar dentro del sistema. Para esto deberemos utilizar los elementos <security-role> y <role-name> dentro del archivo web.xml.

<br /><security-role><br /> <role-name>Admin</role-name><br /></security-role><br /><br /><security-role><br /> <role-name>Member</role-name><br /> </security-role><br /><br /><security-role><br /> <role-name>Guest</role-name><br /></security-role><br />

Una vez definidos los roles, se procede a establecer “declarativamente” el acceso a un conjunto de recursos en combinación con los métodos, a los cuales tendrán accesos determinados roles. El elemento principal es el <security-constraint>.

<br /><security-constraint> <br /><br /> <web-resource-collection><br /> <web-resource-name>ActulizarDatos</web-resource-name><br /> <url-pattern>/cl/jug/actualizar/*</url-pattern><br /> <url-pattern>/cl/jug/listar/*</url-pattern><br /> <http-method>GET</http-method><br /> <http-method>POST</http-method><br /> </web-resource-collection><br /><br /> <auth-constraint><br /> <role-name>Admin</role-name> <br /> <role-name>Member</role-name> <br /> </auth-constraint><br /><br /></security-constraint><br />

Donde:

• El elemento <web-resource-name> es obligatorio y utilizado principalmente por los IDEs.

• El elemento <url-pattern> define el recurso al cual se limitara el acceso. Al menos se debe definir a lo menos un <url-pattern>.

• El elemento <http-method> describe el método HTTP que será restringido para acceder al recurso definido en los <url-pattern>. Si no se define ningún <http-method>, entonces se restringirá el acceso a todos los métodos HTTP.

• El elemento <auth-constraint&gt; es opcional y permite definir cuales roles pueden llamar a los métodos HTTP restringidos por los elementos <http-method&gt;

Para permitir el acceso a todos los roles, se debe definir el elemento <auth-constraint> de la siguiente forma:

<br /><auth-constraint><br /> <role-name>*</role-name><br /></auth-constraint><br />

O también de la forma:

<br /><auth-constraint></auth-constraint><br />

En el caso de que se quiera bloquear el acceso a todos los roles, se deberá definir el <auth-constraint> de la siguiente forma:

<br /><auth-constraint/><br />

Es importante tener en cuenta que se puede tener más de un elemento <web-resource-collection> dentro de un <security-constraint>. En este caso, el elemento <auth-constraint> se aplica a todos los <web-resource-collection> definidos dentro de un <security-constraint>.

Autentificacion

Anteriormente mencionamos que la especificación de servlet ofrece cuatro tipos de autentificación: BASIC, FORM, CLIENT-CERT y DIGEST.

Cada uno de estos tipos se puede definir en el web.xml de siguiente forma:

<br /><login-config> <br /> <auth-method>BASIC</auth-method><br /></login-config><br /><br /><login-config> <br /> <auth-method>FORM</auth-method> <br /> <form-login-config> <br /> <form-login-page>/loginUsuario.html</form-login-page> <br /> <form-error-page>/loginError.html</form-error-page> <br /> </form-login-config><br /></login-config><br /><br /><login-config> <br /> <auth-method>CLIENT-CERT</auth-method><br /></login-config><br /><br /><login-config> <br /> <auth-method>DIGEST</auth-method><br /></login-config><br />

Un punto importante es que de los cuatro tipos de autentificación, el tipo DIGEST es el único que es opcional para los contenedores JEE.

Modos de transporte

La especificación también define tres modos para indicar la seguridad del transporte de los datos a través de la Web.

• NONE: Ningún tipo de cifrado, simplemente HTTP.

• CONFIDENTIAL: Define la confidencialidad de los datos. Es decir, que nadie pueda ver ni modificar los datos que se envían.

• INTEGRAL: Define la integridad de los datos. Es decir, que aunque alguien pueda ver lo que se envía, se garantice que los datos no se modifiquen por el camino.

<br /><security-constraint> <br /><br /> <web-resource-collection><br /> <web-resource-name>ActulizarDatos</web-resource-name><br /> <url-pattern>/cl/jug/actualizar/*</url-pattern><br /> <url-pattern>/cl/jug/listar/*</url-pattern><br /> <http-method>GET</http-method><br /> <http-method>POST</http-method><br /> </web-resource-collection><br /><br /> <auth-constraint><br /> <role-name>Admin</role-name> <br /> <role-name>Member</role-name> <br /> </auth-constraint><br /><br /> <user-data-constraint><br /> <transport-guarantee>CONFIDENTIAL</transport-guarantee><br /> </user-data-constraint><br /><br /></security-constraint><br />

El metodo isUserInRole()

La clase “HTTPServletRequest” tiene tres métodos que están asociados al manejo de la seguridad de manera “programática”, uno de estos es el método “isUserInRole”.

A través del método “isUserInRole()”, en vez de manejar el acceso a nivel de método HTTP, ahora podremos autorizar el acceso a una parte del código de nuestro método basados en los roles del usuario.

Antes de que se llame al método “isUserInRole()”, el usuario necesita estar autenticado. En el caso de que llame al método sobre un usuario que no ha autenticado, el contenedor retornara “false”.

En el caso de que este autenticado, el contenedor toma el argumento del método y compara este con los roles definidos para el usuario en el “request”.

Si el usuario es mapeado a este rol, el contenedor retornara “true”.

Por ejemplo, dentro del código en el servlet:

<br />if( request.isUserInRole(“DukeChile”)) { <br /> // Permiso para actualizar la informacion<br />} <br />else { <br /> // permiso solo para consultar la informacion <br />}<br />

<br /><servlet><br /> <security-role-ref><br /> <role-name> DukeChile </role-name><br /> <role-link>Admin</role-link><br /> </security-role-ref> <br /> ...<br /> </servlet> <br /><br /><security-role> <br /> <role-name>Admin</role-name> <br /></security-role><br />

El elemento <security-role-ref> permite relacionar un <role-name> definido “programáticamente” (en el servlet) con uno que existe en el web.xml.