Componentes Web

Veremos ahora algunos mecanismos que pueden emplearse con HTTP para autentificar (validar) al usuario que intenta acceder a un determinado recurso.

Autentificaciones elementales

El protocolo HTTP incorpora un mecanismo de autentificación básico (basic) basado en cabeceras de autentificación para solicitar datos del usuario (el servidor) y para enviar los datos del usuario (el cliente), de forma que comprobando la exactitud de los datos se permitirá o no al usuario acceder a los recursos. Esta autentificación no proporciona confidencialidad ni integridad, sólo se emplea una codificación Base64.

Una variante de esto es la autentificación digest, donde, en lugar de transmitir el password por la red, se emplea un password codificado. Dicha codificación se realiza tomando el login, password, URI, método HTTP y un valor generado aleatoriamente, y todo ello se combina utilizando el método de encriptado MD5, muy seguro. De este modo, ambas partes de la comunicación conocen el password, y a partir de él pueden comprobar si los datos enviados son correctos. Sin embargo, algunos servidores no soportan este tipo de autentificación.

Certificados digitales y SSL

Las aplicaciones reales pueden requerir un nivel de seguridad mayor que el proporcionado por las autentificaciones basic o digest. También pueden requerir confidencialidad e integridad aseguradas. Todo esto se consigue mediante los certificados digitales.

El encriptado con clave pública se basa normalmente en el algoritmo RSA, que emplea números primos grandes para obtener un par de claves asimétricas. Las claves pueden darse con varias longitudes; así, son comunes claves de 1024 o 2048 bits.

Notar que con este sistema se garantiza la confidencialidad (porque los datos van encriptados), y la integridad (porque si los datos se desencriptan bien, indica que son correctos). Sin embargo, no proporciona autentificación (B no sabe que los datos se los ha enviado A), a menos que A utilice su clave privada para encriptar los datos, y luego B utilice la clave pública de A para desencriptarlos. Así, B descodifica primero el mensaje con su clave privada, y luego con la pública de A. Si el proceso tiene éxito, los datos se sabe que han sido enviados por A, porque sólo A conoce su clave privada.

SSL 3.0 proporciona también soporte para certificados y autentificación del cliente. Funcionan de la misma forma que los explicados para el servidor, pero residiendo en el cliente.

Cualquier aplicación medianamente compleja tendrá que autentificar a los usuarios que acceden a ella, y en función de quiénes son, permitirles o no la ejecución de ciertas operaciones.

Los mecanismos de autentificación en WildFly se basan en el concepto de realm. Un realm es un conjunto de usuarios, cada uno con un login y password y uno o más roles. Los roles determinan qué permisos tiene el usuario en una aplicación web (esto es configurable en cada aplicación a través del descriptor de despliegue, web.xml). El login y el password se utilizará para la autentificación de los usuarios, y los roles para su autorización.

Podemos encontrar distintos tipos de realms, que básicamente se diferencian en dónde están almacenados los datos de logins, passwords y roles. Por defecto en WildFly tenemos dos realms que almacenan estos datos en ficheros de texto de tipo .properties. Existen otros realms que leer los datos de bases de datos con JDBC, de un directorio LDAP o mediante JAAS, el API estándar de Java para autentificación.

Los dos realms que tenemos por defecto en WildFly son ManagementRealm y ApplicationRealm. ManagementRealm se utiliza para la aplicación de administración del servidor, por lo que sólo nos permite controlar la autentificación (no se indican roles porque el único rol que tienen los usuarios de este conjunto es el de administrar el servidor). Por otro lado, ApplicationRealm nos permite además controlar la autorización, mediante la asignación de roles a usuarios.

No será necesario editar manualmente los ficheros de usuarios de estos realms por defecto, ya que se proporciona una herramienta para añadir nuevos usuarios a ellos. Este herramienta se encuentra en el directorio $WILDFLY_HOME/bin, y se ejecuta de la siguiente forma:

Nos preguntará en primer lugar en cuál de los dos realms por defecto queremos introducir el usuario, y a continuación nos irá pidiendo los datos del nuevo usuario. En las aplicaciones que incorporen seguridad declarativa se nos permitirá entrar con cualquiera de los usuarios del ApplicationRealm. Las operaciones que nos permita hacer dependerán de los roles asignados.

En las aplicaciones web Java EE tenemos distintos tipos de autentificación que podemos emplear:

Con la especificación 3.0 de servlets se introduce la posibilidad de configurar los permisos de acceso mediante anotaciones en lugar de en el web.xml, lo que hace la configuración menos farragosa y más clara. La anotación principal que utilizaremos es @ServletSecurity, que toma dos parámetros:

La anotación @HttpConstraint acepta los siguientes parámetros:

Un caso común es aquel en el que queremos permitir acceso al servlet a unos roles determinados:

Si queremos permitir el acceso a cualquier usuario (aunque no esté autentificado), pero siempre mediante SSL, podemos indicarlo de la siguiente forma:

Como alternativa, podemos definir diferentes restricciones para cada método HTTP. Para ello utilizaremos la anotación @HttpMethodConstraint, que podrá tomar los siguientes parámetros:

Si sólo se especifica el método (sin añadir más parámetros), se considera que siempre se permite el acceso mediante dicho método. Por ejemplo, podemos definir políticas diferentes para los métodos GET, POST y PUT:

En este ejemplo, se permite acceder a todos los usuarios con GET, pero con POST sólo podrán acceder los que tengan rol admin, y con PUT no podrá acceder nadie.

También podemos combinar una política particular para una serie de métodos, y una política general para el resto:

En este caso sólo los usuarios con rol admin podrán acceder mediante POST, y sólo se podrán establecer conexiones PUT mediante SSL, pero para el resto de métodos se permitirá acceder a cualquier usuario sin necesidad de utilizar SSL.

Es muy probable que necesitemos acceder desde el código de la aplicación a información del contexto de seguridad del servidor, como puede ser el nombre del usuario autentificado actualmente, o sus roles. Podemos acceder a esta información a través del objeto HttpServletRequest.

En primer lugar, podemos obtener los datos del usuario autentificado actualmente con el método getUserPrincipal() de la petición. Esto nos devolverá un objeto de tipo Principal, del que podremos sacar el nombre del usuario. De forma alternativa, este nombre también se puede obtener mediante el método getRemoteUser() del mismo objeto.

También puede interesarnos comprobar si el usuario actual pertenece a un determinado rol, para así saber si debemos darle permiso o no para realizar una operación dada. Esto lo podemos realizar con el método isUserInRole(rol) del objeto petición.

Otros métodos que nos aportan información sobre el contexto de seguridad son getAuthType(), que nos dice el tipo de autentificación que estamos utilizando (BASIC, DIGEST, FORM, CLIENT-CERT), y isSecure() que nos indica si estamos realizando una conexión segura (SSL) o no.

Para finalizar, si estamos utilizando seguridad basada en formulario podremos cerrar la sesión de forma sencilla llamando al método invalidate() del objeto HttpSession.