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:
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á
You must be logged in to post a comment.