adAS sigue evolucionando, dando más funcionalidad y mejorando las ya existentes.
En su nueva versión, la 1.3.0, tenemos varias novedades importantes. Las comentamos a continuación organizadas según el aspecto a las que son relativas.
Protocolos
- Implementación de Single LogOut en todos los protocolos.
- Añadido el soporte de Policy Agents de OpenSSO.
- Se ha incluído, para facilidad de instalación de adAS y de recursos PAPI un GPoA interno
Metadatos
- Mejora de la sección de editar metadatos del interfaz web de adAS, incluyendo un visor de archivos de metadatos y la capacidad de deshabilitar el acceso a recursos determinados.
- En esta nueva versión es posible, además, acceder a los metadatos de un recurso vía URL.
Temas de usuarios
- Se ha internacionalizado la plantilla de temas para adAS (pantallas de logia, logout, status, etc. tanto para navegadores web como para móviles. Actualmente incluye los idiomas Castellano, Inglés y Catalán; siendo fácilmente ampliable a otros idiomas.
Criptografía
- Añadida la capacidad de cifrado/descifrado de aserciones SAML2 y el soporte de peticiones OCSP firmadas
Autenticaciones
- Incluido, módulo de autenticación delegada para SAML2, además de los existentes (PAPI y Aplicaciones Facebook)
- Implementación de Niveles de Confianza (LoAs) mediante un módulo de definición personalizada de los mismos y la posibilidad de asignar LoAs diferentes a módulos de autenticación y recursos concretos.
- Posibilidad de configurar un WAYF en la pantalla de login que se le muestre al usuario, seleccionando los módulos de autenticación delegada que se quieren incluir en el WAYF.
Administración Web
- Además de mejorar el interfaz web de administración de adAS de forma notable, se ha añadido la posibilidad de configurar un perfil de auditor que pueda entrar en la administración web de adAS, limitando su acceso sólo a las secciones de informes estadísticos.
¿A qué esperas? ¡Descárgate la nueva versión de adAS y pruébala!
Al principio de la era digital, las personas hacían uso de sistemas básicos de autenticación para poder acceder a recursos: si querían acceder al correo de la facultad o acceder a tus datos de matrícula necesitabas tener en tu poder un nombre de usuario y una contraseña específica para ello.
La cosa comenzó a complicarse cuando se vio la necesidad de que profesores subieran documentos e información con acceso restringido a los sistemas de la universidad. Para permitir este acceso comenzaron a necesitarse unas credenciales específicas. Además, la universidad comenzó a ofrecer más y más servicios, usando las credenciales originales u otras nuevas, dependiendo de la aplicación que se utilizara, acabándose por tener una organización con un conglomerado de fuentes de datos, aplicaciones y protocolos heterogéneas e incomunicadas entre ellas.
Para solventar el problema de desorganización, seguridad y eficiencia se ha comenzado a implantar sistemas que unifiquen la gestión de la identidad de las organizaciones mediante proveedores de identidad como adAS o directorios virtuales que concentran la entrada a fuentes de datos como VirDAP.
Hasta este punto, el problema era poder autenticar a los usuarios de nuestra organización en un sólo punto (Single Sign-On); pero una vez resuelto este asunto comienzan a plantearse otras implicaciones: ¿Qué ocurre con los usuarios que no son de mi organización y que quiero que accedan a mi sistema, por ejemplo: usuarios de selectividad, estudiantes extranjeros o de otras universidades?
Para solucionar este aspecto se pensó en la creación de Federaciones, donde universidades y otras organizaciones crean acuerdos entre ellas que permiten que usuarios de unas y otras puedan acceder a los recursos de ambas. Los inconvenientes de una solución federada son importantes, tanto burocráticos como tecnológicos, ya que implican firma de convenios, entrega de información personal de los usuarios, implantación de un sistema común a los integrantes de la federación y el coste (material, tiempo, personal de mantenimiento) que esto suponte, etc.
Quizás es hora de mirar un poco más allá y pensar en una solución diferente, la denominada Autenticación Delegada: ¿Por qué no dejar que los sistemas de cada organización traten con sus propios datos? En un sistema de autenticación delegada se trata la información de la siguiente forma:
- Un usuario quiere acceder a un recurso de la organización X
- Para ello accede a la página de control de acceso de su organización X
- En ella se le permitirle autenticarse con su organización Y, se le redirige al control de acceso de su organización
- El usuario se autentica en Y
- Y responde a X diciéndole si el usuario está autenticado o no
- Y deja acceder al usuario en consecuencia de la respuesta anterior.
Esta solución permite evitar a ambas organizaciones tener que haber implementado una federación y con la mera integración de los Single Sign-On de ambas es posible la autenticación delegada, sin traspaso de más información personal de los usuarios que la imprescindible, evitando la creación de cuentas duplicadas y eliminado la necesidad de que el usuario tenga que aprenderse/utilizar otro tipo de credenciales más.
Y ahora bien, nos queda el problema de decidir de qué organizaciones nos fiamos más o menos, por ejemplo, si un alumno de la universidad quiere cambiar sus datos bancarios, ¿nos fiamos de cualquier autenticación delegada? Incluso dentro de nuestra propia organización puede que querramos utilizar certificados o DNIe en vez de usuario y contraseña para ciertos trámites. La pregunta que nos queda es ¿Cuáles son los sistemas más confiables? ¿Qué orden de confianza le doy a mis sistemas de autenticación, tanto local como delegada?
Para responder a esta pregunta habrá que implantar lo que se denominan Niveles de Confianza (LoA, Level of Assurance). De ellos ya hablaremos en posteriores entradas del blog.
Continuará 
El próximo 6 de octubre en la Universidad de Cuenca tendrá lugar el II Foro de Identidad de RedIRIS. En este encuentro, la Universidad de Salamanca y la Universidad de Girona presentarán respectivamente adAS como su nuevo SSO .
La USAL se centrará en cómo permite adAS la autenticación de sus usuarios a través del DNIe y cómo se gestionan los atributos necesarios para cada aplicación a través de las Fuentes de Datos en adAS.
La UdG en cambio presentará el acceso a Google Apps que se permite a través de adAS para sus usuarios.
Más información:
Ya está disponible la versión 1.2 de adAS. Para los que no lo conozcáis, éste es un Servidor de Autenticación Avanzado que realiza funciones de Proveedor de Identidad en protocolos como PAPI, SAML 2 y OpenSSO, ofreciendo a su vez un entorno gráfico de configuración.
Nuevo tema adAS
Son muchas las nuevas características principales de adAS 1.2, por lo que las hemos dividido en las siguientes categorías:
- Protocolo:
- Se ha añadido el protocolo OpenSSO dentro de esta versión de adAS. Actualmente cubre el interfaz REST de OpenSSO.
- Metadatos:
- Firma digital de los metadatos propios que genera el interfaz de administración.
- Metadatos de Proveedores de Servicio del protocolo OpenSSO. Se permite definir la IP desde la que se permite el acceso al interfaz REST de OpenSSO.
- Metadatos extendidos: un nuevo formato de metadatos que permite incluir nueva información sobre los originales de un Proveedor de Servicio sin modificar su firma digital. Esta característica se utiliza para generar un identificador opaco a cada uno de los Proveedores de Servicio que se hayan incluido, el cual permanecerá inmutable aunque se modifique el ID de entidad (entityID).
- Fuentes de datos:
- Se ha incluido una nueva fuente de datos: Oracle. Ésta es configurable a través del interfaz OCI8 de PHP.
- Posibilidad de no cachear atributos de un usuario, permitiendo así la generación de valores dinámicos en cada petición que reciba adAS.
- Se permite definir una lista de índices en una fuente de datos. Así, podemos realizar la autenticación o la obtención de atributos utilizando diferentes índices sobre una misma fuente de datos.
- Autenticación:
- Se ha incluido una nuevo módulo de autenticación local: Oracle.
- Posibilidad de que el usuario elija cómo se quiere autenticar en el caso de que se haya obtenido más de un identificador único en su proceso de identificación.
- Autenticación delegada:
- adAS soporta ahora la delegación de la autenticación en otros entornos. Además, opcionalmente se puede comprobar si el usuario existe en nuestra organización antes de indicar que la autenticación ha sido correcta.
- Nuevos módulos de autenticación delegada:
- Atributos:
- Se ha incluido el soporte de esquemas de atributos:
- eduPerson
- SCHAC
- iris.schema
- inetOrgPerson
- Posibilidad de definir si se quiere enviar los atributos en modo OID o URN en una política de emisión de atributos de un Proveedor de Servicio. La información del OID y el URN se obtendrá del esquema de atributos que se haya configurado.
- Se ha incluido el soporte de esquemas de atributos:
- Interfaz de administración:
- Se permite proteger el interfaz de administración como un Proveedor de Servicio PAPI, por lo que la autenticación queda delegada a la que se tenga configurada en el adAS.
- Nueva sección que permite configurar el interfaz de administración visualmente.
Además de resolver los bugs o errores que se habían informado hasta la fecha. Esta nueva versión ha sido posible gracias al apoyo de las universidades de Salamanca, Girona y Málaga.
Como son muchas las nuevas características, iremos analizando las más importantes una a una en este blog
Ah! Podéis descargar esta nueva versión en la página de descarga de adAS y si tenéis alguna duda os recomendamos que os suscribáis a la lista de correo de usuarios de adAS.