Servicio de Autentificación Centralizado

De Wiki-SIC
Saltar a navegación, buscar

La Junta de Castilla-La Mancha dispone de un servicio de autentificación de usuarios centralizado, que se puede usar como método de validación de usuarios para cualquier aplicación de la Junta. Un único inicio de sesión sirve para validarse en todas las aplicaciones adaptadas a este sistema, siempre que se abran en el mismo navegador que inició sesión en el sistema.

Sso-login.jpg

Se trata de un sistema Single Sign On basado en el producto CAS de la empresa JA-SIG, y valida a los usuarios contra el directorio LDAP corporativo de la Junta, a través del UID y contraseña de cada usuario (las mismas credenciales que se usan, por ejemplo, para el correo electrónico).

Para poder usar el servicio es necesario incorporar a la aplicación que quiera usarlo una librería cliente. Existen multitud de clientes en diferentes lenguajes que se pueden incorporar a cualquier desarrollo de la Junta. En el siguiente enlace se encuentra la documentación para todos ellos:

https://wiki.jasig.org/display/CASC/Official+Clients

A través de las funciones que proporcionan las librerías cliente, las aplicaciones pueden obtener algunos atributos LDAP básicos del usuario autentificado, para así realizar las tareas pertinentes.

Los parámetros necesarios para conectar con el servicio son:

Hostname: sso.jccm.es
Port: 443
Service URI: cas-jccm

A continuación se expondrán algunas cuestiones técnicas. Todas las funciones indicadas se refieren al cliente oficial de CAS para PHP (phpCAS), aunque tienen su equivalente en el resto de clientes.

Manejo de sesiones

Los tiempos de sesión locales de aplicación y de SSO son independientes. El tiempo de sesión por defecto en CAS es de ocho horas para cada servicio, entendiendo "servicio" como la URL que pidió el login. Por ejemplo, si la URL de login de una aplicación es http://app.jccm.es/app/login, y ésta redirige a CAS para mostrar la pantalla de inicio de sesión, CAS creará un "ticket" en el que asocia el usuario logado con el "servicio" (la URL). El servidor realiza una búsqueda y limpieza de tickets caducados cada media hora.

Los tiempos de sesión tanto locales como del servidor se refieren a tiempos de inactividad. Es decir, cualquier llamada pondrá a cero el contador de tiempo de sesión.

Si una aplicación utiliza más de una URL para hacer login, puede generar varios servicios en el servidor CAS, cada uno de ellos con un tiempo de sesión distinto, y provocar situaciones difíciles de controlar en el cliente. Es por tanto muy conveniente que nuestras aplicaciones tenga un único punto de acceso al login.

En una operativa normal, la aplicación al iniciar sesión crea una sesión local y otra en CAS. La sesión local de la aplicación puede ser manejada por la misma, o delegar su manejo al cliente CAS. Para ello basta con poner a TRUE el último parámetro de la llamada a phpClient::client() o phpClient::proxy(). Mientras la sesión local dure, no se volverá a consultar al servidor CAS (a menos que se le llame explícitamente). Si la sesión local ha caducado, el cliente CAS consultará al servidor CAS por si todavía existe sesión viva en él. En tal caso, la aplicación cliente puede volver a iniciar sesión local automáticamente sin que el usuario tenga que introducir de nuevo su clave, ya que la llamada a phpClient::getUser() devolverá un usuario válido.

Para identificar a sus clientes, el servidor CAS escribe una cookie en el navegador. Por lo tanto, para que un único inicio de sesión en CAS permita el acceso a múltiples aplicaciones, éstas deben abrirse en el mismo navegador (típicamente en distintas pestañas de una misma ventana).

Si el navegador se cierra o se borran las cookies, se pierde dicha identificación y es necesario volver a iniciar sesión. Debido a esta mecánica, y por motivos obvios de seguridad, es muy recomendable cerrar nuestro navegador al finalizar una jornada de trabajo.

Single Sign Out

El servidor CAS provee un mecanismo de Single Sign Out, es decir, un logout único para todas las aplicaciones cliente.

Cuando un ticket para un servicio caduca, el servidor CAS envía un mensaje POST al la URL del servicio asociado al ticket. Este mensaje puede ser capturado por phpClient::handleLogoutRequests() para proceder al cierre de sesión local. Para ello las sesiones de la aplicación las tiene que manejar el cliente CAS (habiendo puesto a TRUE el correspondiente parámetro en client() o proxy()).

Para que handleLogoutRequest() pueda capturar las peticiones, lógicamente tiene que ser llamado bajo la misma URL del servicio que utiliza CAS para hacer la petición. Por ejemplo, si la URL de login de una aplicación es http://app.jccm.es/app/login, y ésta redirige a CAS para mostrar la pantalla de inicio de sesión, esta URL será el servicio que CAS asocie al ticket, y es a la que llamará para lanzar el mensaje de logout. Por lo tanto, en el código de nuestra aplicación debemos asegurar que la llamada a dicha URL lance en algún momento la función phpCAS::handleLogoutRequests(), que se encargará de destruir la sesión local.

Cuando un usuario hace logout en el servidor CAS, bien directamente (accediendo a https://sso.jccm.es/cas-jccm/logout) o bien a través de una aplicación cliente que lance phpClient::logout(), el servidor lanza un mensaje de logout a todos los servicios que tenga asociados al usuario. Como hemos dicho, queda a expensas de las aplicaciones el capturar o no correctamente estos mensajes.

Es importante señalar que si las aplicaciones clientes que han de recibir la llamada de Single Sign Out están replicadas tras un balanceador de carga, deben clusterizarse de manera que mantengan sus sesiones replicadas en todo momento, ya que la persistencia del balanceador no funcionará en este caso al ser el CAS un cliente distinto del navegador del usuario.


Si necesita asistencia o desea reportar alguna incidencia, puede dirigirse via CRU al Servicio de Internet y Comunicaciones.

Herramientas personales
Espacios de nombres
Variantes
Acciones
Navegación
Información General
Webmail
Otras cosas
Herramientas