Beneficios del SIR


Información sobre la nueva federación SIR2

La nueva federación SIR2 ya se encuentra en marcha. En este momento se está procediendo a contactar a los administardores de proveedores de identidad de la federación SIR, para indicarles el procedimiento de migración de su proveedor de identidad a la nueva federación.

Mientras concluye la migración de IdPs, los nuevos SPs, salvo el caso concreto de SPs Cl@ve, seguirán registrándose a través de la federación SIR.

Hemos escrito un artículo describiendo las distintas fase de migración, las cuales hemos documentado más extensamente en las páginas de la nueva federación.

Para cualquier duda, podéis seguir utilizando el formulario de contacto de SIR, o si está relacionada con la nueva federación, cualquiera de las vías mencionadas en la sección 'Contacto' de las páginas de la nueva federación.

El Servicio de Identidad de RedIRIS ofrece a las instituciones que se adhieren al servicio la posibilidad de acceder a recursos protegidos por aquellos proveedores de servicio que así lo han concertado con RedIRIS.

Introducción

A día de hoy, las organizaciones han tenido la necesidad de proteger el acceso a determinados recursos, donde sus usuarios tienen que autenticarse previamente si quieren acceder a ellos. La autenticación es el proceso mediante el cual el usuario se identifica en su organización y, en el caso que todo haya ido correctamente, obtiene unas credenciales con la información de su identidad.

El siguiente paso que se ha iniciado en este proceso de seguridad en la infraestructura de la organización ha sido permitir el acceso al recurso dependiendo de qué rol o atributos tenga relacionado el usuario. A este proceso lo llamamos autorización, y permite una granularidad más fina en la seguridad del entorno, ya que no todos los usuarios podrán acceder a los mismos recursos.

Para aquellas organizaciones que quieren o necesitan acceder a recursos protegidos tanto de su entorno como de otras entidades, el usuario que quiera acceder a una aplicación web tendrá, por lo general, que realizar la autenticación en cada una de dichas aplicaciones, siendo los procedimientos más comunes escribir nombre de usuario/contraseña o identificarse mediante huella digital.

Este escenario conlleva una serie de desventajas, siendo la raíz de ellas que el usuario necesitará una identificación diferente, aunque sean los mismos valores en cada una de ellas, por cada aplicación web. No sólo es un problema para el usuario, ya que su organización, y en general cada una que necesite autenticarlo, tiene que mantener en diferentes sistemas de almacenamiento múltiples entradas de identificación de un mismo usuario.

Los principales factores negativos de este escenario son:

  • Aumento de los costes de tiempo en el registro y administración de los usuarios, ya que todas las organizaciones tienen que gestionar cuentas de identidad para ellos, en la mayoría de los casos sin posibilidad de automatizar el proceso.
  • Aumento de los costes de recursos físicos, puesto que hay un aumento exponencial del uso de la red y de los sistemas hardware que se necesitan. Ya no tenemos la información de los usuarios de nuestra organización sino que debemos almacenar el de todas las organizaciones.
  • Posibilidad de que ocurran inconsistencias en los sistemas que almacenan los datos de un usuario en las distintas organizaciones.
  • Los usuarios deben recordar múltiples pares nombre de usuario y contraseña. Esto provoca que la seguridad del sistema tenga una fuerte dependencia en ellos, siendo un foco principal de problemas con respecto a la seguridad de los sistemas.

Las infraestructuras federadas de autenticación y autorización tienen como objetivo delegar la identificación de cada usuario en la organización a la que pertenece, en la cual se realizará el proceso de autenticación una sola vez. Este proceso es conocido como Single Sign-On. Cada vez que el usuario quiera acceder a un recurso protegido, tendrá que presentar las credenciales obtenidas al autenticarse.

output

De esta forma, podemos ver que cuando implantamos una federación, el usuario quiere acceder a determinados recursos protegidos tanto en su organización como en una externa. En este nuevo escenario identificamos dos componentes principales en una federación:

  • Proveedor de identidad: realiza la autenticación del usuario y emite sus credenciales. éstas no sólo contienen información sobre si la autenticación ha sido correcta, sino que también incluirá una serie de atributos asociados a él. En el caso de una universidad, reflejaría por ejemplo si el usuario es un alumno o un profesor. El objetivo es reducir al máximo la información más sensible del usuario, como su nombre y apellidos, y basar los derechos de acceso en qué tipo de usuario es.
  • Proveedor de servicio: comprueba las credenciales del usuario, y en el caso de que no sean válidas o suficientes, o bien el usuario no las haya obtenido previamente, deniega el acceso al recurso protegido.

Para acceder a un recurso protegido en una federación, en un primer momento (paso 1 en la figura anterior) realizará el proceso de autenticación en el proveedor de identidad de su organización. Gracias a esta acción, obtendrá sus credenciales, las cuales generalmente están encriptadas de manera que sólo el proveedor de identidad y los proveedores de servicio puedan leerlas. En el momento que quiera acceder a una aplicación web de su organización (paso 2 en la figura anterio), no tendrá que volver a identificarse, sino que en la misma petición envía también sus credenciales. Nos encontramos con el mismo caso cuando acceda a la aplicación web (paso 3 en la figura anterior) de la organización externa que ha instalado un proveedor de servicio para proteger su recurso.

Las ventajas que ofrece este escenario federado son:

  • Las organizaciones no tienen que registrar los datos de los usuarios de otras organizaciones. Además de no aumentar los costes de tiempo en gestionar usuarios de otras entidades, se reduce la complejidad de las políticas de seguridad y no interfiere en el cumplimiento de las leyes de protección de datos.
  • Los usuarios sólo tienen que recordar su nombre en el sistema y su contraseña. Aumenta la seguridad de la infraestructura.
  • Los recursos son ofrecidos a los usuarios de todas las organizaciones que participan en la federación, sin que el usuario tenga que solicitar el acceso a cada uno de los recursos.

Características de SIR

Una vez que la institución se incluye en el servicio se convierte un proveedor de identidad válido dentro de la federación gestionada por el SIR.

De esta forma, se le facilita a todo proveedor de identidad una serie de interfaces de salida que pueden ser utilizadas por las instituciones incluso fuera del ámbito de este servicio:

output

PAPI

La interconexión de una institución en esta federación se basa en el protocolo definido por PAPI v1, por lo cual todo proveedor de identidad tiene disponible su propio Servidor de Autenticación (AS) de PAPI, una vez que ha terminado de unirse a este servicio.

Shibboleth

Cada proveedor de identidad también tiene asociado un Identity Provider (IdP) de Shibboleth, permitiendo así poder acceder recursos protegidos por dicha tecnologí, como por ejemplo Microsoft DreamSpark. El IdP se anuncia en un fichero de metadatos, base de la confianza de la federación, donde se puede obtener información sobre su despliegue. En el caso de que la institución ya tuviera desplegado un IdP, RedIRIS ofrece la posibilidad de incorporar su metadato en el SIR por lo cual no sería necesario que tuviera otro IdP en el SIR.

eduGAIN

SIR es el punto de salida desde las instituciones afiliadas a RedIRIS hacia eduGAIN, una red de federaciones europeas promovida por la red académica paneuropea GéANT2. En el momento que haya recursos protegidos a través de este servicio, estarán disponibles automáticamente en el SIR.

openID

Todos los usuarios de los proveedores de identidad en SIR tienen un identificador vá de openID (tanto en su protocolo v1 como en v2). El nombre de usuario viene dado de la siguiente forma:

http://yo.rediris.es/soy/nombre_de_usuario@dominio_institucion.org

Donde,

  • nombre_de_usuario: es el nombre del usuario proporcionado por su institución
  • dominio_institucion.org: es el dominio principal en internet de la institución del usuario

En caso de duda, existe un servicio, PAPOID Finder, en SIR que informa al usuario de su identificador de openID, evitando la molesta de preguntar en su proveedor de identidad.

Además, existen versiones del identificador también en catalán, euskera y gallego, disponibles para todos los usuarios.