El uso de aplicaciones web ha aumentado drásticamente en los últimos años. La facilidad de uso junto a la comodidad para actualizar y mantener este tipo de aplicaciones ha hecho que vayan ganando terreno con respecto a los sistemas de escritorio. La aparición de clientes ricos desarrollados con Ajax o componentes ActiveX permiten lograr funcionalidades en aplicaciones web que previamente solo estaban disponibles en aplicaciones de escritorio.

Sin embargo, no todo es una ventaja. El tener muchas aplicaciones web, especialmente dentro de un entorno de los llamados intranet, implica que cada aplicación deberá tener sus propias rutinas de validación, algo no muy´bueno de cara al cliente y no muy aceptable a nivel administrativo y de seguridad informática.

Una de las soluciones pasa por usar alguna herramienta de Single Sign On, lo cual implica que un usuario se va a validar solo una vez contra un validador central y que todas las aplicaciones aceptaran dicha validación.
CAS

Una de las herramientas disponibles en el mercado es CAS (Central Authentication Service) desarrollado por la Universidad de Yale.

La idea del funcionamiento de CAS es sencilla.

A cada aplicación web se le agrega un filtro el cual, en realidad, es un cliente de CAS. Cuando alguien llama a alguna de las aplicaciones protegidas por CAS, el filtro toma el control y procede a verificar si el cliente (el browser cliente) ha sido validado. Si no lo ha sido, el filtro redirije el flujo de navegación hacia la pagina de Login de CAS.

CAS esta desarrollado con Spring y hace uso de todos sus atributos. Al momento de realizar un Login, Spring genera una clase Credential con los datos facilitados por el formulario y CAS se encarga de buscar un handler que se encargue de validar ese tipo de login, de esa forma el sistema esta abierto a varios tipos de validaciones.

Cuando CAS encuentra el handler adecuado, procede a pasarle el control y este realiza la validación y devuelve un resultado exitoso o una excepción (la cual tambien puede y debe ser adaptada a cada situación).

Si el resultado es exitoso, CAS genera un ticket que viaja en un cookie. Dicho ticket es opaco, no lleva ningun tipo de dato que pueda afectar la seguridad ya que es solo un hash code que solo CAS puede interpretar. Cuando el filtro cliente vuelve a recibir el ticket de CAS, este deriva el flujo de navegación a la aplicación que había sido originalmente llamada por el cliente.

Ahora bien, si una aplicación cliente ya ha sido validada por CAS, puedo llamar a otra aplicacion cliente. Cuando hago esto, el filtro deriva nuevamente el flujo de navegación hacia CAS pero con el ticket contenido en el cliente. CAS verificará que el ticket es válido y procederá de forma similar al método usado en el login.

El procdedimiento es sencillo, pero resulta muy eficiente.

CAS trabaja tambien con Acegi, el cual agrega algunas funcionalidades al cliente comun de CAs y (creo) permite incluso realizar Single Sign On con aplicaciones de escritorio.

El sistema tambien puede ser adaptado para realizar validaciones via Web Services.