ESPECIFICACIONES TÉCNICAS DEL ACCESO FEDERADO A LOS SISTEMAS DE ENSEÑANZA VIRTUAL DE...

ESPECIFICACIONES TÉCNICAS DELACCESO FEDERADO A LOS

SISTEMAS DE ENSEÑANZA VIRTUAL DE LAS UNIVERSIDADES ANDALUZAS QUE

CONFORMAN EL CAMPUS ANDALUZ VIRTUAL

Índice de contenido1.Introducción.......................................................................................................................................32.Requisitos generales..........................................................................................................................43.Especificaciones................................................................................................................................5

3.1. Identificación de atributos de conexión....................................................................................53.2. Identificación de atributos y mecanismos de provisión............................................................53.3. Módulos de conexión................................................................................................................53.4. Mecanismos de provisión.........................................................................................................53.5. Módulos de extracción..............................................................................................................53.6. Adaptación de procesos y documentos de CAV.......................................................................6

4.Servicios de implantación en las instituciones participantes.............................................................75.Organización y coordinación del proyecto: fases, plazos de ejecución, composición equipo decisorio...............................................................................................................................................8

5.1. Equipo de Trabajo.....................................................................................................................85.1.1. Comité de Seguimiento.....................................................................................................85.1.2. Jefe de Proyecto................................................................................................................8

5.2. Fases del Trabajo y Entregables. Plazos de ejecución..............................................................86.Presupuesto de Licitación..................................................................................................................97.Criterios de valoración de las ofertas..............................................................................................108.Coordinación de los trabajos...........................................................................................................119.Referencias......................................................................................................................................1210.Glosario.........................................................................................................................................1211.Anexo I (Recomendaciones relativas a la implantación de una infraestructura federada de identidad para las universidades andaluzas).......................................................................................1312. Anexo 2 (Caso de uso del Campus Andaluz Virtual.)..................................................................13

12.1. Descripción ..........................................................................................................................1312.2. Objetivos ..............................................................................................................................1312.3. Acceso de los alumnos a la plataforma de enseñanza virtual de otra universidad ...............1412.4. Condiciones previas .............................................................................................................14

Versión 0.2 - 28 de Octubre de 2008

Página: 2

1. Introducción

Este documento define las especificaciones técnicas básicas que han de regir la contratación del desarrollo e implantación posterior de los elementos para que los sistemas integrados en el Campus Andaluz Virtual hagan uso de la Infraestructura de Identidad Federada de las Universidades de Andalucía (CONFIA).

El objetivo final de los trabajos a contratar es incluir los sistemas de enseñanza virtual(LMS) de las universidades que participan en el Campus Andaluz Virtual (CAV) como proveedores de servicios (SPs) de la federación, de tal manera que los alumnos matriculados en una universidad en asignaturas que se imparten en otra, puedan acceder al sistema de esta última con las credenciales de su universidad de origen, identificándose en el proveedor de identidad (IdP) de ésta.

Además, esto se debe hacer teniendo en cuenta la legalidad vigente en cuanto al intercambio electrónico de datos personales y proponiendo procesos que mejoren los flujos de trabajo y reduzcan al mínimo imprescindible la cantidad de datos personales que sea necesario intercambiar.

Es importante reseñar desde el inicio que cada universidad puede utilizar el sistema, o sistemas, de enseñanza virtual que considere adecuado.

Para conseguir estos objetivos se requiere realizar, al menos:● Identificar los atributos necesarios para el uso y la provisión en los LMS.● Determinar mecanismos adecuados de provisión para poder usar los LMS.● Desarrollar los módulos de conexión para los LMS en uso en las universidades

participantes.● Desarrollar los módulos de provisión para los LMS en uso en las universidades

participantes.● Desarrollar los módulos necesarios para extraer información de los sistemas de

registro de las universidades participantes.● Propuestas de mejora de los flujos de trabajo y documentación del CAV en función

del conocimiento adquirido.


Página: 3

2. Requisitos generales

Proporcionar la infraestructura software necesaria que permita la implantación del sistema ofertado por el licitador. Se valorará positivamente el uso de software libre. En caso de que el sistema ofertado incluya software propietario, se entenderá que el licitador aportará las licencias necesarias para todos los participantes, durante un periodo mínimo de cinco años. Se penalizará, en todo caso, la dependencia de de software o servicios de carácter comercialEl desarrollo del sistema debe hacerse mediante lenguajes y herramientas de programación estándar y de uso suficientemente extendido, con facilidad de mantenimiento, seguros y no dependientes de productos comerciales, siempre que sea posible.

El código fuente del proyecto debe aportarse íntegramente a la federación en formato digital y será licenciado bajo una licencia de código abierto (GPL, Apache) etc… Se valorará el modelo de licencia seleccionado.

La empresa adjudicataria se compromete a hacer todo lo posible por contribuir e incluir el código de conexión a la federación al código fuente base (upstream) de los LMS de código abierto.

Los LMS que están en uso en las universidades que participan en el CAV y, por tanto, que deberán conectarse a CONFIA como resultado de los trabajos contratados, son:

● WebCT

● Moodle

● ILIAS


Página: 4

3. Especificaciones

El ANEXO I del presente documento contiene el documento de referencia técnica de la federación [RAUPAAI] y el ANEXO II la descripción del caso de uso del Campus Andaluz Virtual definido por el grupo de trabajo [RCAV].

A continuación se detallan los elementos a desarrollar objeto de este pliego.

3.1. Identificación de atributos de conexión

Se deberán determinar los atributos que el IdP de la Universidad de origen del alumno deberá enviar al LMS que actúa como SP en la aserción SAML, para que lo pueda identificar y le permita acceder a los contenidos y recursos a los que tiene derecho.

3.2. Identificación de atributos y mecanismos de provisión

Se deberán determinar los mecanismos por los que los alumnos realizarán la primera conexión con los LMS y se determinará la información que debe intercambiarse para que se creen todas las entidades necesarias en dicho sistema para que en sucesivas conexiones el alumno pueda acceder a aquellos contenidos a los que tiene derecho. En este punto es importante activar los mecanismos de consentimiento informado y políticas de liberación de atributos. Igualmente se debe identificar un proceso seguro para el intercambio de dichos datos personales, si es posible, sin que pasen por el navegador del usuario, por ejemplo, utilizando OAuth.

3.3. Módulos de conexión

Se deberán desarrollar los módulos necesarios para cada uno de los LMS en uso que permitan identificar al usuario por mecanismos federados, recibir los atributos necesarios establecidos en 3.1 e iniciar una sesión en el sistema.

3.4. Mecanismos de provisión

Se deberán desarrollar los módulos necesarios para que el proceso definido en 3.2 resulte en la provisión de la información y creación de los objetos de datos que requiera cada LMS para incluir como propio al alumno y asignarle los recursos a los que tenga derecho.

3.5. Módulos de extracción

No toda la información requerida para realizar la provisión ha de encontrarse necesariamente en el sistema de gestión de identidad de la universidad de origen. Es


Página: 5

posible que parte de la información se encuentre en los sistemas de registro, habitualmente el sistema de gestión académica. Por esto, será necesario desarrollar los procesos y módulos necesarios para que el mecanismo de provisión pueda obtener la información necesaria para enviar al LMS del sistema de registro y enviarla al por el canal adecuado.

3.6. Adaptación de procesos y documentos de CAVUna vez probados los sistemas y procesos se realizará una propuesta de mejora de los procesos y documentación actual del Campus Andaluz Virtual basada en la experiencia adquirida con el uso del sistema desplegado como resultado del presente pliego.


Página: 6

4. Servicios de implantación en las instituciones participantes.

El adjudicatario será responsable de desplegar los desarrollos resultantes de los trabajos objeto de la licitación en las instituciones participantes, en estrecha colaboración con el personal técnico de las mismas y bajo la supervisión del mismo y del comité de seguimiento.El personal externo habrá de contar con la experiencia profesional y los conocimientos necesarios para la realización de las tareas requeridas (a criterio de la institución y oído el comité de seguimiento).


Página: 7

5. Organización y coordinación del proyecto: fases, plazos de ejecución, composición equipo decisorio.

5.1. Equipo de Trabajo.

5.1.1. Comité de Seguimiento.Se designará un grupo de personas que constituirán el Comité de Seguimiento, cuyas funciones son las siguientes:

Resolver cualquier duda técnica sobre los términos de este pliego.

Velar por el cumplimiento de los objetivos del proyecto.

Actuar como interlocutor y punto de contacto preferente para la comunicación entre las instituciones participantes y el adjudicatario, resolviendo conjuntamente las cuestiones sobrevenidas que puedan afectar a la ejecución de cualquiera de las obligaciones derivadas de la adjudicación.

El comité supervisará de forma periódica (con una cadencia mínima de un mes) conjuntamente con el jefe de proyecto, la adecuación de los trabajos a los objetivos propuestos.

5.1.2. Jefe de Proyecto.El adjudicatario designará un Jefe de Proyecto, que lo representará ante el Comité de Seguimiento, y que será el responsable de la ejecución correcta en tiempo y forma de las obligaciones derivadas de la adjudicación.

5.2. Fases del Trabajo y Entregables. Plazos de ejecución.

El trabajo deberá estar finalizado en un plazo máximo de seis meses, incluyendo la documentación. Su evolución será certificada mensualmente mediante comisiones de seguimiento.Será responsabilidad del Jefe de Proyecto junto con la Comisión de Seguimiento determinar los prerrequisitos de cada entregable.El proyecto se descompone en los siguientes paquetes de trabajo y entregables:

● Paquete de trabajo número 1: AtributosIncluye los trabajos relativos al intercambio de atributos, con los siguientes entregables:

1. Identificación de atributos para uso2. Identificación de atributos para provisión3. Especificaciones de provisión

● Paquete de trabajo número 2: WebCTIncluye los trabajos relacionados con el LMS WebCT, con los siguientes


Página: 8

entregables:1. Módulo de conexión2. Mecanismo de provisión

● Paquete de trabajo número 3: MoodleIncluye los trabajos relacionados con el LMS Moodle, con los siguientes entregables:

1. Módulo de conexión2. Mecanismo de provisión

● Paquete de trabajo número 4: ILIASIncluye los trabajos relacionados con el LMS ILIAS, con los siguientes entregables:

1. Módulo de conexión2. Mecanismo de provisión

● Paquete de trabajo número 5: DespliegueIncluye todas las tareas necesarias para el despliegue de los desarrollos de los otros cuatro paquetes de trabajo, con los siguientes entregables:

1. Despliegue de los módulos de conexión en cada LMS de las instituciones2. Despliegue del módulo de extracción de cada institución3. Despliegue de los módulos de provisión en cada LMS de las instituciones

● Paquete de trabajo número 6: PolíticaIncluye un único entregable con la documentación de mejora de procesos y propuestas de adaptación de los documentos del CAV.

Las entregas se producirán de acuerdo a los siguiente hitos, siendo X el día de adjudicación del concurso:

Entrega PlazoP1 P2 P3 P4 P5 P6

E1 E2 E1 E2 E1 E2 E1 E2 E1 E2 E3 E1

E#1 X + 90

E#2 X + 180

6. Presupuesto de Licitación.

El presupuesto máximo de licitación es de 90.599 €, IVA incluido, debiéndose licitar a la baja. No se aceptarán en ningún caso las ofertas que superen el presupuesto máximo de licitación.


Página: 9

7. Criterios de valoración de las ofertas.

La oferta deberá contener como parte principal una memoria técnica que describa con suficiente precisión:

El planteamiento del licitante en relación con el proyecto La solución técnica ofertada, tanto en lo que respecta a la arquitectura general del sistema como a los componentes que la integran y sus interfaces La especificación de las tecnologías y productos disponibles que constituyen la base de partida de la solución propuesta

La oferta deberá contener una declaración expresa de aceptación y acatamiento de todas y cada una de las cláusulas del presente pliego.Los criterios de evaluación de las ofertas son la calidad técnica con un 85 por ciento de la ponderación y el importe económico ofertado con un 15 por ciento de ponderación

Importe económico: se asignará la mayor puntuación a la oferta que resulte más ventajosa para la Universidad, es decir, a la que oferte el presupuesto más bajo, siempre que no incurra en situación de temeridad. Se valorará de acuerdo con la siguiente formula:

Pb= 15 * Bb/Bmax.

Siendo:

Bb: el porcentaje de baja correspondiente al presupuesto ofertado.

Bmax: el porcentaje de baja máxima ofertada, sin considerar las que resulten temerarias según el criterio expuesto a continuación.

Los resultados se redondearán con una (1) cifra decimal.

Se considerarán que son bajas temerarias las correspondientes a aquellas ofertas económicas que sean inferiores en DIEZ puntos o más a la que resulte ser la baja media.

El concepto que la Universidad hará de la calidad técnica de la oferta se basará en los siguientes conceptos (ponderados cada uno de ellos sobre el 85 por ciento correspondiente al concepto “Calidad técnica“):

A. Entendimiento de la problemática (25 puntos)

Se valorará la comprensión de la problemática planteada así como la idoneidad del enfoque de la solución propuesta.

B. Solución aportada (30 puntos)

Se valorará el planteamiento metodológico y su adecuación a la consecución de los


Página: 10

objetivos del proyecto.

Se valorarán los tiempos de ejecución del proyecto, y especialmente los planteamientos viables con tiempos de ejecución iguales o inferiores a los preestablecidos.

C. Implantación (20 puntos)

Se valorará la definición de las pruebas de aceptación así como las de rendimientos.

Asimismo serán criterios a valorar la definición del escenario de implantación, el plan de puesta en explotación del sistema y el plan de formación.

D. Aportación de valor añadido (10 puntos)

Las mejoras se entienden como aquellas condiciones que la Comisión calificadora estime que aumentan el interés de la propuesta, no estando previstas en el pliego de condiciones, y no formando parte del presupuesto de licitación.

A modo de resumen, se incluyen en la siguiente tabla, los criterios de valoración de las ofertas, con sus diferentes pesos:

CRITERIO PESO Importe económico 15 puntos Calidad técnica 85 puntos

A. Entendimiento de la problemática

25 puntos

B. Solución aportada 30 puntos C. Implantación 20 puntos D. Aportación de valor añadido

10 puntos

TOTAL 100 puntos

8. Coordinación de los trabajos.

El adjudicatario del presente pliego debe coordinarse tanto con las universidades constituyentes de la federación andaluza como con el adjudicatario del pliego de “acceso federado a los sistemas de enseñanza virtual de las universidades andaluzas que conforman el campus Andaluz Virtual”.


Página: 11

9. Referencias

[LOPD] Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal

[RAUPAAI] Recomendaciones relativas a la implantación de una infraestructura federada de identidad para las universidades andaluzas (CONFIA)

[RCAV] Caso del uso del Campus Andaluz Virtual: http://federacion22.us.es/wiki/index.php/CampusAndaluzVirtual

10. Glosario

SP: Del inglés “Service Provider” (proveedor de servicio). El proveedor de servicio es un sistema que protege recursos accesibles a través de la red. Cuando un usuario intenta acceder a un recurso protegido por el SP, el sistema localiza (normalmente, con ayuda del usuario) el IdP de la institución a la que pertenece el usuario. El usuario es redirigido a su IdP para que se autentique y una vez que se ha autenticado correctamente, el SP obtiene los atributos del IdP necesarios para saber si tiene o no derechos de acceso al recurso.

IdP: Del inglés “Identity Provider” (proveedor de identidad). El IdP se encarga de autenticar a un usuario en una institución cuando intenta acceder a los recursos de un sitio protegido por un SP, garantizando que efectivamente ese usuario es miembro de dicha institución. Una vez autenticado, el IdP le proporciona al SP los atributos necesarios sobre el usuario. Basándose en estos atributos, el SP otorgará o denegará el acceso al usuario de los recursos en cuestión.

LMS: Del inglés “Learning Management System” (Sistema de Gestión del Aprendizaje). También Sistemas de Enseñanza Virtual. Sistemas utilizados para enseñanza a distancia por medio de mecanismos de Internet, principalmente basados en web.


Página: 12

11. Anexo I (Recomendaciones relativas a la implantación de una infraestructura federada de identidad para las universidades andaluzas)-Incorporado al final de este documento, tras anexo 2-

12. Anexo 2 (Caso de uso del Campus Andaluz Virtual.)

12.1. Descripción El Campus Andaluz Vritual(CAV) es un elemento clave del proyecto *Universidad Digital* (Consejería de Innovación, Ciencia y Empresa de la Junta de Andalucía) que promueve una docencia completamente virtual y a distancia. El CAV se sustenta en las plataformas de enseñanza virtual de todas las universidades públicas andaluzas y es coordinado por el grupo UVAS. (tomado de la página web del Campus Andaluz Virtual en sep07). En el CAV cada universidad participante ofrece varias asignaturas que se imparten con la plataforma de enseñanza virtual de su universidad. Los alumnos de las asignaturas provienen de todas las universidades que participan en el CAV. El acceso de los alumnos a las plataformas de universidades distintas a la universidad en la que se han matriculado requiere la transferencia de datos entre universidades, pero es muy difícil transmitir con seguridad las claves de acceso, por lo que los alumnos tienen claves e identificadores distintos en cada universidad con la que se relacionan. Para la coordinación e intercambio de datos entre las universidades se utiliza un portal común, actualmente situado en www.campusandaluzvirtual.es. Este portal tiene una parte de información general, noticas etc. y otra parte de gestión del intercambio de los datos entre las universidades. En este portal de gestión es donde cada universidad introduce los datos personales de sus alumnos y recoge los datos personales de los alumnos matriculados en las asignaturas que imparte. Además se utiliza para agilizar el intercambio de actas con las calificaciones de los alumnos. La utilización de una infraestructura de identificación y autenticación son de utilidad en 2 aspectos diferentes del proyecto: las interacciones de los usuarios (alumnos, profesores, personal administrativo) con el portal de información y gestión, y las interacciones de los alumnos con las plataformas de enseñanza virtual, siendo esta última la más interesante y útil.

12.2. Objetivos El objetivo fundamental de aplicar la federación de identidades al Campus Andaluz Virtual es conseguir que los alumnos puedan acceder a las plataformas de otras universidades con la misma clave que utilizan para acceder a la plataforma de enseñanza virtual de su propia universidad. Además, utilizando la misma tecnología los estudiantes, profesores y personal técnico y administrativo pueden acceder al portal del CAV usando su identificación y utilizar recursos específicos para cada uno.


Página: 13

12.3. Acceso de los alumnos a la plataforma de enseñanza virtual de otra universidad A continuación se enumeran los sucesos principales que ocurren durante la identificación de un alumno para la utilización la plataforma de enseñanza virtual de una universidad de la federación.

1.El alumno accede a la página web de la plataforma donde se imparte la asignatura. Cómo consigue la dirección de esa página web depende de la universidad en que se matriculó. En el portal del CAV se encuentran las direcciones de las plataformas de todas las universidades participantes.

2.En esa página hay algún enlace o botón (u otro artefacto) que lleva al alumno hasta la página web del "Where are you from? (WAYF)". El WAYF muestra los proveedores de identidad que pueden ser utilizados por el alumno.

3.El alumno selecciona el *proveedor de indentidad (IdP)* que quiere utilizar, que será el que corresponda a la clave que utiliza en la plataforma de su universidad, y es dirigido hacia la página de dicho proveedor.

4.En la página del IdP el alumno introduce su identificador y clave habitual y es dirigido automáticamente a la página web de la plataforma donde se imparte la asignatura. El navegador del alumno (programa Firefox, Safari, Opera, Internet Explorer, ...) recibe un mensaje seguro de autenticación que se entregará automáticamente cuando se conecte a la plataforma donde se imparte la asignatura.

5.Al conectarse (tras la redirección automática) a la página web de la plataforma donde se imparte la asignatura, el navegador (programa) entrega el mensaje a la plataforma, que conoce así la identidad del alumno y el IdP utilizado.

6.La plataforma comunica con el IdP a fin de obtener algunos datos más del alumno, por ejemplo los códigos de asignaturas del CAV en los que está matriculado, el correo electrónico del alumno, etc. Este intercambio de datos debe ajustarse a las normas de la federación.

7.La plataforma muestra al alumno las asignaturas que el alumno puede cursar y continua la interacción alumno/plataforma.

El intercambio de datos que se produce en el penúltimo punto debe ser discutido en profundidad dentro del proyecto CAV; sin embargo, puede adelantarse que todas las asignaturas incluidas en el CAV reciben un código de 9 cifras que las identifica unívocamente y que podría utilizarse para que el IdP especificase a que asignaturas tiene derecho a acceder el alumno.

12.4. Condiciones previas Cada universidad debe configurar un proveedor de servicios (SP) para su plataforma de enseñanza virtual, especificando que proveedores de identidad miembros de la federación serán admitidos como IdP válidos. Hay que tener en cuenta que la federación puede crecer incluyendo otros miembros que no tengan nada que ver con el CAV, y que, por tanto, se ha de mantener una lista de los IdP que serán reconocidos en el CAV.


Página: 14

ANEXO I

Recomendaciones relativas a la implantación de una infraestructura federada de identidad

para las universidades andaluzas

ÍndiceIntroducción......................................................................................................................................................3

1.1. Modelo general de una infraestructura federada de identidad...............................................................42. Federaciones de identidad............................................................................................................................5

2.1. SWITCHaai (Suiza)................................................................................................................................52.2. UK Access Management Federation (Reino Unido)..............................................................................52.3. Haka (Finlandia)....................................................................................................................................62.4. Feide (Noruega).....................................................................................................................................6

3. Esquemas de federación y directorios corporativos......................................................................................74. Identidad federada y sistemas SSO..............................................................................................................85. Protocolos y perfiles......................................................................................................................................9

5.1. Perfil básico para acceso Web..............................................................................................................95.2. Formato de metadatos...........................................................................................................................95.3. Determinación del IdP de origen..........................................................................................................105.4. Privacidad. Gestión de derechos de acceso a los atributos.................................................................115.5. Esquema de confianza........................................................................................................................11

5.5.1. Perfiles de los certificados ........................................................................................................125.5.2. Política de certificación y declaración de prácticas de certificación ..........................................135.5.3. Validación TLS ..........................................................................................................................135.5.4. Validacion de la firma XML........................................................................................................13

6. Integración de aplicaciones........................................................................................................................136.1. Tipos de protección de aplicaciones Web ...........................................................................................14

6.1.1. Páginas estáticas o aplicaciones que no contemplan control de acceso ..................................146.1.2. Aplicaciones que admiten plugins de autenticación/autorización .............................................146.1.3. Aplicaciones con mecanismos cerrados de autenticación/autorización ....................................146.1.4. Aplicaciones que son un interfaz o proxy para otro servicio que requiere autenticación ..........15

6.2. Obtención de atributos.........................................................................................................................156.3. Paso de atributos a la aplicación ........................................................................................................15

7. Casos de uso..............................................................................................................................................167.1. Campus Andaluz Virtual......................................................................................................................16

7.1.1. Objetivos....................................................................................................................................177.1.2. Condiciones previas..................................................................................................................177.1.3. Descripción detallada.................................................................................................................177.1.4. Cuestiones abiertas...................................................................................................................18

7.2. Transferencia de ficheros. Aplicación Consigna..................................................................................187.2.1. Condiciones previas..................................................................................................................187.2.2. Descripción detallada.................................................................................................................197.2.3. Atributos.....................................................................................................................................197.2.4. Cuestiones abiertas...................................................................................................................19

7.3. Registro recíproco de usuarios de biblioteca ......................................................................................197.3.1. Solución propuesta....................................................................................................................207.3.2. Condiciones previas..................................................................................................................207.3.3. Descripción detallada.................................................................................................................207.3.4. Atributos.....................................................................................................................................207.3.5. Cuestiones abiertas ..................................................................................................................21

7.4. Provisión de cuentas............................................................................................................................217.4.1. Solución propuesta ...................................................................................................................217.4.2. Condiciones previas..................................................................................................................227.4.3. Atributos.....................................................................................................................................22

7.5. Aula de informática virtual....................................................................................................................227.5.1. Solución propuesta....................................................................................................................237.5.2. Condiciones previas..................................................................................................................237.5.3. Descripción detallada.................................................................................................................237.5.4. Atributos.....................................................................................................................................24

8. Referencias.................................................................................................................................................24

Versión 5.0 – 28 de Octubre de 2008Página: 2

IntroducciónLa identidad constituye un elemento estratégico en organizaciones de cualquier índole, dado que es la base para el acceso a los servicios y la información institucionales. Gestionar adecuadamente los mecanismos de autenticación y autorización se está convirtiendo en una tarea cada vez más relevante (y en algunas ocasiones, complicada) para las instituciones académicas. Especialmente si tenemos en cuenta que la naturaleza abierta de las mismas implica de manera natural que la comunidad de usuarios está sometida a un cambio continuo.

Estos cambios no sólo afectan a los individuos que pertenecen a la institución sino también a sus papeles dentro de la misma. El coste de mantener sistemas de identidad electrónica, credenciales de autenticación y roles de autorización es alto. Y es conveniente recordar que tanto los aspectos de seguridad como las demandas de colaboración a nivel nacional e internacional son altos y crecen de manera continuada.

Las infraestructuras de autenticación y autorización (IAA) y, en especial, los esquemas que permiten su integración por medio de mecanismos de federación, son un componente esencial de las infraestructuras TIC de las instituciones académicas y administrativas en la actualidad y son elementos fundamentales para la consecución de uno de los objetivos de importancia radical en el entorno académico europeo, como es la puesta en práctica del Proceso de Bolonia.

Estas infraestructuras son elementos clave para la implantación de servicios como el correo corporativo, los sistemas de e-learning y un amplio conjunto de aplicaciones que pueden ser solicitadas de manera autónoma por los usuarios (acceso a expedientes, reserva de espacios comunes, acceso a recursos bibliográficos, actualizaciones de software, etc.). Extender estos servicios a toda la comunidad académica sin los mecanismos que proporciona una IAA es enormemente costoso en términos de recursos humanos.

Las mejoras en los servicios integrales que constituyen los objetivos de una universidad (investigación y docencia) son incluso más relevantes si se utiliza una IAA con capacidad de federación, que permita el establecimiento de lazos de confianza entre las instituciones participantes. Estas mejoras están directamente imbricadas con los objetivos del Proceso de Bolonia, especialmente en los casos de proyectos de investigación internacionales y de la movilidad de estudiantes.

La colaboración en tareas de investigación se ve enormemente facilitada por el uso de herramientas colaborativas, cuyo acceso y administración son mucho más simples en el caso de disponer de una IAA federada. Estos mecanismos constituyen la base fundamental del nuevo paradigma de colaboración por medio de lo que se ha dado en llamar e-ciencia: las organizaciones virtuales. Estas organizaciones virtuales permiten no solo el uso de determinados recursos por sus miembros, sino también (y eso diferencia este concepto de otros anteriores) facilitan la incorporación de nuevos miembros y, aún más, simplifican el compartir recursos por parte de aquéllos que pueden ofrecerlos. Es importante notar aquí la idea de que los servicios se centran en la comunidad de usuarios, que emplean el soporte middleware ofrecido por las IAA e infraestructuras similares para que los propios usuarios utilicen los recursos ofrecidos por las redes de comunicaciones para facilitar su interacción. Evidentemente, el paradigma de las organizaciones virtuales es perfectamente aplicable a otros campos, como la docencia o las facilidades para la interacción entre estudiantes.

Un sistema federado de gestión de identidad reduce también de forma significativa el alto coste comparativo de la incorporación de estudiantes (especialmente extranjeros) de acuerdo con los mecanismos de movilidad asociados con el proceso de Bolonia, facilitando la aplicación automática de los intercambios de datos previstos en el European Credit Transfer System (ECTS): una IAA federada permite la verificación de los datos relevantes de un nuevo estudiante procedente de otra institución por medio de la adecuada referencia a la identidad electrónica del nuevo estudiante.


1.1. Modelo general de una infraestructura federada de identidad

La figura siguiente ilustra los componentes de un sistema federado de identidad. En los extremos aparecen, por un lado, el repositorio de datos sobre los usuarios ubicados en una cierta institución (institución origen, IO) participante y, por el otro, los recursos que ofrece otra de las instituciones (institución remota, IR). La infraestructura permite a los usuarios de la IO acceder a los servicios en la IR utilizando sus datos de identidad local, y a los responsables de la IR decidir los permisos de acceso a sus recursos de manera autónoma. Los datos entre las dos instituciones se intercambian por medio de un conjunto de protocolos acordados para la infraestructura federada.

De izquierda a derecha, es decir, de la IO a la IR, los elementos intervinientes en la federación son:

1. El repositorio de identidad en la IO, gestionado de manera independiente por los responsables de la misma. Se corresponde típicamente con un directorio corporativo de personal y estudiantes.

2. Los mecanismos de adaptación del esquema local al esquema de la federación. El esquema local se aplica en el entorno de la IO y, por tanto, es decidido de manera autónoma por la misma. Como es evidente, el intercambio de datos de identidad entre los participantes en la federación debe ajustarse a unas reglas de sintaxis y semántica comunes.

3. El Proveedor de Identidad (IdP en sus siglas en inglés comúnmente empleadas), encargado de enviar los datos de identidad requeridos a partir del repositorio de identidad local. Actúa como productor de aserciones de identidad.

4. El protocolo de federación, que regula el intercambio de los datos de identidad.

5. El Proveedor de Servicio (SP en sus siglas en inglés comúnmente empleadas), encargado de requerir y procesar los datos de identidad enviados por el IdP y de hacerlos llegar a los servicios locales. Actúa como consumidor de aserciones de identidad.

6. Los metadatos que permiten a IdPs y SPs establecer los lazos de confianza necesarios tanto para (en el caso del IdP) estar seguros que los datos se envían a un receptor autorizado de los mismos, como para (en el caso del SP) poder establecer la autenticidad de la fuente de los datos. Los metadatos constituyen la espina dorsal de la federación y deben ser gestionados por una entidad en la que los participantes depositen su confianza.


7. Los mecanismos de adaptación del esquema de la federación a las aplicaciones locales en la IR. Cada aplicación suele requerir mecanismos específicos para explotar los datos de identidad, aunque existen técnicas comunes para su interconexión con los SPs e incluso propuestas de estandarizar APIs para ello.

8. Como es evidente, las aplicaciones en la IR tomarán sus decisiones de acceso y personalización en función de los datos recibidos y de la política de uso de la institución, de manera completamente autónoma.

2. Federaciones de identidadComo referencia para este documento, el grupo de trabajo ha analizado las características de las federaciones de identidad académicas ya implantadas o en proceso de implantación en países de nuestro entorno. Esta sección ofrece un resumen de las mismas.

2.1. SWITCHaai (Suiza)

Los estudios preliminares comienzan a finales del 2001. La federación es operativa desde agosto del 2005. Los IdPs asociados dan cobertura a 175.000 usuarios de educación superior, un porcentaje superior al 75%.

En la actualidad, el número de IdPs es de 26 (SWITCHaai Home Organizations), comprendiendo universidades, escuelas técnicas, hospitales, centros de investigación, el VHS (Virtual Home Organization Service) y socios tecnológicos. El número de SPs ofrecidos por los participantes superan los 180. La SWITCHaai participa en la confederación eduGAIN, bajo los auspicios de GÉANT2.

Los servicios más relevantes son:

● E-learning: ILIAS, CASUS, Claroline, Dokeos, Moodle, OLAT, VITELS, WebCT.

● Bibliotecas y bases de datos: DigiTool, EBSCO, ScienceDirect.

● Aplicaciones web: BSCW, Compicampus, eConf Portal, EVA, Jahia, OpenCMS, Plone, SLCS, Sympa, Twiki, WebSMS.

● Servicios comerciales y socios tecnológicos: Tribunal Federal, Neptun Store, MSDNAA.

● Herramientas: AAI Portal, ArpViewer, Group Management Tool, Resource Registry, Virtual Home Organization Service (para usuarios sin identidad en la AAI), WAYF Service.

2.2. UK Access Management Federation (Reino Unido)

La federación es operativa desde noviembre del 2006. Abarca a 108 organizaciones asociadas (“Member Organizations”), comprendiendo universidades y “colleges” (“Higher Education”), escuelas profesionales (“Further Education”), escuelas primarias y secundarias (“Schools”), centros de investigación y organizaciones e instituciones que proveen servicios a las anteriores.

En la actualidad, el número de IdPs es de 63 y el número de SPs ofrecidos por las organizaciones asociadas es de 71. Conviven recursos basados en Shibboleth y en el antiguo sistema centralizado Athens haciendo uso de pasarelas.



● E-learning: BMJ Learning, eSTEP Foundation.

● Bibliotecas y bases de datos: CAB Abstracts, CrossFire, EBSCO, Education Image Gallery (archivo Getty), Landmap, ScienceDirect, SilverPlatter WebSPIRS

● Herramientas colaborativas: JANET Videoconferencing Booking Service, JISCmail

2.3. Haka (Finlandia)

La federación es operativa desde agosto del 2005. Agrupa únicamente instituciones de educación superior. El número de miembros es de 26 “Federation Members” y 2 “Federation Partners”. Las instituciones asociadas dan cobertura a 213.000 usuarios de educación superior, un porcentaje en torno al 75% de los eduPersons definidos y el 90% en Universidades.

El número de IdPs operativos es de 13, dando servicio a 159.000 usuarios finales (51% de los eduPersons definidos), comprendiendo únicamente instituciones de educación superior. El número de SPs ofrecidos por los “Federation Members” y “Federation Partners” es de 20. Haka participa en la Kalmar Union (una confederación de federaciones de identidad de los paises nórdicos) y en eduGAIN.


● E-learning: A&O, Moodle (varias Universidades), Optima, TRAKLA2.

● Bibliotecas y bases de datos: MatTaFi, Nelli, Pirkka, Teemu, Wilma.

● Intranet de FUNET.

2.4. Feide (Noruega)

La federación es operativa desde mayo del 2003. Las organizaciones afiliadas comprenden instituciones de educación superior y escuelas primarias y secundarias. Los Proveedores de Identidad (IdPs) asociados dan cobertura a 140.000 usuarios, en torno a 73% de usuarios de educación superior y 89% de usuarios en universidades .

El número de IdPs es de 17 y el número de SPs es de 27. Participa en la Kalmar Union y eduGAIN, e interopera con MinID (el servicio de identidad digital del gobierno noruego). En la actualidad se está investigando y probando la integración con OpenID.


● E-learning.

● Bibliotecas y bases de datos.

● Aplicaciones web: Intranets, Sympa, Wiki.

● Servicios a las instituciones: Compra de licencias software académicas, servicios administrativos, sistemas de seguimiento.


3. Esquemas de federación y directorios corporativosUn directorio puede verse como una base de datos especializada con una serie de características específicas derivadas de su ámbito de aplicación y sus patrones de uso, mientras que el término esquema se refiere a los tipos de información que se almacenan en el directorio, qué reglas debe cumplir dicha información y cómo se realizan las operaciones de búsqueda sobre estos datos. En la actualidad el servicio de directorio más extendido es LDAP (Lightweight Directory Access Protocol) y, de hecho, en la práctica se trabaja con una correspondencia directa entre esquemas de intercambio de datos de identidad y los esquemas de acceso a estos datos a través de LDAP. Por ello, el modelo de referencia de LDAP se emplea a lo largo de esta sección del documento en aras de tener un marco común acorde con la práctica establecida. Como es evidente, cualquier sistema de directorio capaz de proporcionar una semántica compatible con este modelo es completamente acorde con las recomendaciones contenidas aquí.

En realidad, LDAP es un protocolo de acceso a directorios sobre TCP/IP definido en [RFC 3377]. Habitualmente, los datos de un directorio LDAP siguen un modelo de organización de información en árbol según [X500]. Una de las ventajas de un almacén LDAP frente a otros como, por ejemplo, SQL, es que aquellos atributos que no se utilizan, no ocupan espacio de almacenamiento en los objetos almacenados. Por tanto, en el resto del documento el término LDAP equivale a directorio accesible por el protocolo LDAP y el término esquema a las reglas de representación e intercambio de datos especificados de acuerdo a la sintaxis definida por LDAP. Existen tecnologías que permiten agregar datos desde diversas fuentes y presentarlos por medio de LDAP y que pueden ser una solución a los problemas de fragmentación de identidad y de adaptación de esquemas.

En cualquier caso, disponer de un directorio LDAP corporativo es la piedra angular para un sistema de gestión de identidad. En un entorno federado es vital establecer un conjunto de atributos y esquemas comunes para el intercambio de información sobre las personas. Los atributos y valores se pueden generar bajo demanda en el momento en que son solicitados, pero, si existe un directorio corporativo, es más simple tener los atributos y valores previamente provisionados. Además, esto puede facilitar el intercambio de información por otros medios, si fuese necesario, o extender el conjunto de datos solicitados por la federación sin tener que modificar nada en los proveedores de identidad. Los esquemas se pueden ver como una serie de capas superpuestas.

El orden de los esquemas propuestos es:

1. Person

2. orgPerson

3. inetOrgPerson [RFC2798]

4. eduPerson [EDUPERSON]

5. SCHAC [SCHAC]

6. irisPerson [SCHIRIS]

No se recomienda la creación de atributos locales a la federación, puesto que uno de los objetivos es servir de punto de partida a una posible federación de nivel nacional o a otras federaciones regionales. Además, existe la capacidad de influir, en mayor o menor medida, en los tres últimos niveles. Los atributos necesarios serán específicos de cada servicio federado y se definirán en los correspondientes casos de uso.

Sí es importante establecer la conveniencia de disponer de identificadores opacos para los objetos que contengan identidad de personas, de tal manera que, si es necesario, se pueda ocultar la identidad de quién utiliza el servicio frente al proveedor del mismo. En este sentido, se recomienda el uso de cadenas opacas en los nombres distinguidos (DN) de las entradas de personas para el intercambio de datos.


Es interesante resaltar el hecho de que, a nivel institucional, la autenticación centralizada es preferible a la autenticación distribuida, ya que se está mostrando como la solución de menor riesgo, más capaz y con mejor coste. Además, para un sistema de federación, permite que cada institución participante presente un único proveedor de identidad, lo que reduce la complejidad y, por tanto, la fricción, entendida como recursos malgastados. Por otra parte, estos mismos mecanismos de federación permiten la existencia de diversos sistemas de autenticación dentro de una institución, pero este caso disminuye el nivel de confort de los usuarios, principalmente por problemas de credenciales múltiples, y aumenta innecesariamente el nivel de complejidad de los sistemas, al mismo tiempo que reduce las posibilidades de selección de soluciones, ya que el número de ellas que disponen de mecanismos de federación aún es reducido.

Por último, es obvio que debe establecerse un nivel mínimo de calidad en cuanto a la recolección, manejo, almacenamiento y trasferencia de datos de identidad, a fin de cumplir la ley, incrementar la seguridad y preservar la confidencialidad y privacidad de las personas.

4. Identidad federada y sistemas SSOEl concepto Single Sign-On (SSO) se refiere al acceso a múltiples recursos por medio de un único proceso de autenticación. La utilización de un sistema de este tipo nace, por un lado, de la necesidad de garantizar la seguridad de los servicios y por otro, de la posibilidad de ofrecer al usuario un único punto de entrada a todas las aplicaciones a las que podría acceder validándose una sola vez ante un sistema de autenticación.

En la arquitectura SSO tradicional, todos los algoritmos de autenticación (AuthN) y autorización (AuthR) se encuentran en un solo servidor SSO que actúa como el único punto de autenticación para un dominio definido. Así, hay un segundo beneficio de la aproximación SSO para autenticación/registro: un usuario sólo tiene que autenticarse una vez. En el escenario más simple de SSO, en primer lugar, la aplicación llama al servidor SSO y pide el token de autenticación que la identifica. Para poder obtener el token, primero debe proporcionar las credenciales de autenticación correctas. Hay varias formas para estas credenciales: pueden ser, por ejemplo, un sencillo username/password o un certificado X.509, pero también se podrían implementar otros métodos. El servidor SSO realiza una validación de las credenciales del usuario, y sólo entonces envía un ticket que utiliza para autenticarse frente a otras aplicaciones. En el escenario simple, el token no incluye ninguna información específica, simplemente es la identificación única para el usuario en algún ámbito y tiempo definidos. La autorización es un problema local a la aplicación.

Una aproximación más avanzada permite al propio token contener alguna información de AuthR importante que permite la validación sin tener que llamar al servidor SSO cada vez. El token contiene la información de autenticación y autorización. Esta información está firmada por el servidor SSO, suponiendo que el receptor del token confíe en el servidor SSO, no necesita hacer ninguna verificación posterior. Para este intercambio de información relacionada con la autorización se puede utilizar SAML (Security Assertion Markup Language). Básicamente, la información de AuthR descrita por SAML se expresa en forma de sentencias de aserciones. SAML define el protocolo mediante el cual el consumidor del servicio envía la solicitud y la autoridad devuelve la respuesta a través de aserciones.

Un sistema SSO basado en identidad federada desacopla la obtención de datos de AuthN y AuthR del control de acceso, permitiendo el intercambio de estos datos por medio de una infraestructura de confianza. Los mecanismos de SSO pueden de este modo aplicarse a través de diferentes entornos de confianza, proporcionando una mucha mejor experiencia a los usuarios en los escenarios de uso típicos en cualquier aplicación colaborativa.

Las principales ventajas de un sistema de SSO son evidentes:

• Multiplataforma : Facilita las tareas de inicio de sesión y de acceso a recursos de red desde distintas plataformas.

• Transparencia : El acceso a los recursos se efectúa de forma transparente al usuario debido a la automatización del inicio de sesión.


• Facilidad de uso : El usuario se autentica una única vez y el sistema le permite acceder a los recursos para los cuales esta autorizado. Así se evita las interrupciones producidas por la solicitud de usuario y contraseña para el acceso a diferentes recursos.

• Gestión sencilla : El uso de SSO permite el uso de un repositorio único de contraseñas e información de los usuarios.

• Mejor gestión de la seguridad : La implementación, el despliegue y el mantenimiento son más fáciles ya que ninguna de las partes del sistema necesita implementar individualmente todas las características y mecanismos de AuthN y AuthR. De esta manera, no necesitamos proteger mediante TLS o mecanismos similares todas las aplicaciones, basta hacerlo del lado del IdP.

• Mayores garantías de privacidad; El único punto que acepta credenciales de seguridad es el propio servidor SSO. Además, la solución SSO permite la federación, por lo que la autenticación se puede realizar en un ámbito enorme (fuera del dominio de autenticación particular) mientras que las credenciales de AuthN permanecen dentro del dominio de seguridad particular. En este sentido, no están accesible a las aplicaciones la clave del usuario (factor importante cuando el código fuente de las aplicaciones puede ser modificado por personal que no sea de toda confianza para recolectar claves, por ejemplo).

• Facilidad para los desarrolladores : Un sistema SSO provee a los desarrolladores de aplicaciones de una infraestructura de autenticación común.

5. Protocolos y perfilesLa federación de las universidades andaluzas utilizará el protocolo SAML 2.0, tanto para el intercambio de datos para le definición de los metadatos, de acuerdo con las especificaciones de OASIS y de las reglas específicas descritas en este documento.

Los siguientes apartados detallan el uso de estos protocolos en los diferentes escenarios contemplados por la federación, así como en lo necesario para establecer los lazos de confianza entre sus componentes.

5.1. Perfil básico para acceso Web

Este perfil será de aplicación cuando los usuarios intenten acceder cualquier recurso que ofrezca un interface Web estándar (por medio de HTTP y HTTPS) por medio de un navegador Web.

Las interacciones de acuerdo a este perfil se ajustarán a los procedimientos descritos para los perfiles SSO de SAML 2.0 en [SAML2P] y los bindings definidos por [SAML2B], de acuerdo con las siguientes reglas:

● SE RECOMIENDA que los SPs utilicen el binding HTTP Redirect, aunque el uso del binding HTTP POST PUEDE emplearse cuando el tamaño de la AuthenticationRequest exceda los límites prácticos de la codificación en URLs.

● Los IdPs DEBEN emplear en sus respuestas el binding HTTP POST.

5.2. Formato de metadatos

El modelo de información de metadatos de la federación estará definido según las especificaciones de metadatos de SAML 2.0 [SAMLMD], y será utilizado para describir los elementos que interactúan dentro de la federación de una manera formalizada. Esta información se usará principalmente con dos propósitos:


• Identificar los elementos válidos en la federación, así como los interfaces de los mismos, en coordinación con el esquema de confianza de la federación.

• Localizar los componentes capaces de satisfacer una determinada petición de datos de identidad.

Los metadatos de la federación se podrán acceder de manera conjunta como un solo documento XML conteniendo como elemento raíz EntitiesDescriptor, donde cada una de las instituciones participantes estará representado por un elemento EntityDescriptor. En función de los diferentes mecanismos de acceso a los metadatos, será también posible acceder a elementos EntityDescriptor individuales.

Dentro de un elemento EntityDescriptor, al menos uno de los siguientes elementos RoleDescriptor deberá estar presente:

• IDPSSODescriptor, para el interface del IdP, capaz de responder peticiones de autenticación que incluyan información relativa a atributos.

• SPSSODescriptor, para el interface del SP.

Opcionalmente, también podrá aparecer un RoleDescriptor del tipo:

• AttributeAuthorityDescriptor , para el interface del IdP capaz de responder peticiones adicionales de atributos.

Para cada entidad descrita en los metadatos deberán también incluirse datos de gestión:

• Definición de la institución, incluyendo su dominio y el método de autenticación que utilizan sus usuarios.

• Persona(s) de contacto, responsable(s) de mantener la información de la institución en el modelo de información de metadatos.

5.3. Determinación del IdP de origen

En aquellos perfiles en los que los usuarios sean requeridos para la determinación de su correspondiente IdP, la federación dará soporte al menos a las siguientes alternativas:

• Un servicio común a la federación, conocido como WAYF (Where Are You From), con un interface basado en redirecciones HTTP. Este WAYF recibe una petición del SP, interacciona con el usuario y accede a los metadatos para determinar el IdP en cuestión, devolviendo el resultado por medio de una redirección HTPP al SP. En este caso, las interacciones entre SP y WAYF requieren verificaciones de identidad para establecer un canal fiable.

• Un servicio WAYF local en el dominio de la IR al que pertenece el SP. A diferencia del caso anterior, puede usarse un protocolo propio de conexión SP-WAYF y la necesidad de establecer canales fiables se ve atenuada por el hecho de colocar ambos servicios en el mismo dominio. Sin embargo, pueden aparecer problemas de actualización de los metadatos.

• Interfaces de usuario capaces de integrar el mecanismo de WAYF en la interacción directa con el usuario (requiriendo un NetID, por ejemplo) y accediendo a los metadatos por medio de un servicio Web.

Para dar soporte a estas alternativas la federación contará, al menos, con:

1. Un interface Web WAYF común para los usuarios, utilizable por defecto por cualquier SP que participe en ella.

2. Un servicio Web de acceso a los metadatos, para facilitar la implementación tanto de interfaces WAYF locales como de mecanismos integrados como los descritos anteriormente.


5.4. Privacidad. Gestión de derechos de acceso a los atributos

Un aspecto de vital importancia a considerar en el campo de la federación de identidades, por cuanto implica el intercambio de información de usuarios entre instituciones, es el relativo al respeto de la privacidad del usuario y por supuesto, el cumplimiento de la legislación al respecto. Este último aspecto se complica aún más si intervienen elementos (proveedores de servicio, usuarios, etc.) de entornos con legislaciones diferentes. El sistema de federación debe por tanto tener en cuenta estos aspectos como uno de sus principios básicos de diseño y ser lo suficientemente flexible para adaptarse a legislaciones diversas y en continua evolución.

Los mecanismos de gestión universitaria actualmente en uso están evolucionando para adaptarse completamente a los requerimientos de privacidad y en muchos casos no garantizan que el usuario tenga un conocimiento claro (y por medios simples) del uso de sus datos, por mucho que los objetivos de estos usos sean considerados legítimos. De acuerdo con los mismos principios en los que se basa, una federación de identidades cuenta con los mecanismos tecnológicos y logísticos para que este conocimiento y control sean realmente efectivos.

En la práctica, es necesario prever que cualquier atributo de los usuarios puede ser considerado sujeto a las regulaciones en relación al intercambio de datos personales. Por tanto, la información intercambiada debe mantenerse siempre en el mínimo imprescindible para el funcionamiento del servicio que está accediendo. Es importante que ese principio sea aplicado tanto por los SPs a la hora de especificar sus requerimientos, como por los IdPs a la hora de analizar sus políticas de entrega de atributos.

En último término, cada usuario individual debe retener el control sobre qué atributos se entregan a un determinado proveedor de servicio, ofreciéndole la posibilidad de conocer que datos van a ser transferidos antes de que esa transferencia tenga lugar y aceptar o denegar la entrega de estos datos. Lógicamente, para obtener un consentimiento informado, será necesario advertir al usuario de las consecuencias que la denegación de ciertos datos personales puede tener en cada caso, desde la denegación total de acceso a una degradación en la calidad del mismo.

En consecuencia, es un requisito imprescindible disponer de mecanismos para facilitar:

1. La gestión de políticas de entrega de atributos (ARP, “Attribute Release Policy”) a nivel institucional.

2. La gestión directa de ARPs por parte de los usuarios que así lo requieran.

3. La aceptación informada por parte del usuario de la entrega de determinados datos.

Deben proveerse procedimientos para facilitar tanto el cumplimiento de las normas relativas a datos personales como la usabilidad del sistema y su facilidad de gestión. Para conciliar estos requisitos se consideran especialmente relevantes el uso de atributos de definición de preferencias de seguridad (como schacUserPrivateAttribute) para gestionar los ARPs y el empleo de mecanismos interactivos de aceptación que hagan uso de las declaraciones de requisitos de los SPs expresadas en los metadatos.

5.5. Esquema de confianza

La federación requiere un modelo de confianza que permita a sus componentes validar la identificación de cada uno de ellos durante las interacciones. La confianza estara establecido usando TLS para las conexiones y firma digital para los elementos del protocolo.

Toda la confianza residirá en una Infraestructura de Clave Pública (PKI), basada en certificados X.509, que está formada por una serie de Autoridades de Certificación (CA) validadas para el esquema de confianza. De esta forma, se establecerá un procedimiento mediante el cual una CA podrá ser admitida dentro del


esquema de confianza. La federación distribuirá por métodos fuera de línea (correo electrónico firmado con PGP, repositorio fiable basado en la tecnología TACAR, etc.) las raíces de confianza correspondientes a las CAs reconocidas.

5.5.1. Perfiles de los certificados

Todos los certificados emitidos por cualquier CA válida en el esquema de confianza de la federación se ajustarán al perfil PKI para Internet (PKIX) de certificados X.509 [RFC3280]. Estas CAs sólo podrán emitir certificados X.509.

Las siguientes extensiones de los certificados X.509 estarán presentes en todos los certificados admisibles para la federación:

• Para un certificado de CA:

• Basic Constraints (critical): ca: true

• Subject Key Identifier: <hash>

• Authority Key Identifier: <keyID>

• Key Usage (critical): digitalSignature, nonRepudiation, KeyCertSign, cRLSign

• Extended Key Usage: timeStamping

• CRL Distribution Points: <URI>

• Certificate Policies: <OID>

• Para un certificado de componente de la federacion:

• Basic Constraints (critical): ca: false

• Subject Key Identifier: <hash>

• Authority Key Identifier: <keyID>

• Key Usage (critical): digitalSignature, nonRepudiation, KeyCertSign, cRLSign

• Extended Key Usage: timeStamping

• CRL Distribution Points: <URI>

• Certificate Policies: <OID>

• Subject Alternate Name : El identificador apropiado en la federación, el cual, tal como se describe en el RFC 3280, es una URL con el identificador almacenado en formato URN como parámetro.

Los OIDs para los algoritmos usados para la creación de firmas de los certificados emitidos por las CAs reconocidas por la federación son:


• Función hash: id-sha1 1.3.14.3.2.26

• Cifrado: rsaEncryption 1.2.840.113549.1.1.1

• Firma: sha1WithRSAEncryption 1.2.840.113549.1.1.5

Cada entidad tendrá un único Distinguished Name (DN) en todos los certificados emitidos para ella por su correspondiente CA. El DN estará estructurado tal como se define en [X501].

Todas las CAs reconocidas por la federación crearán y publicarán Listas de Revocación de Certificados (CRL) en formato X.509v2. Se deben emitir CRLs completas con independencia del motivo de la revocación, la cual no debe ser incluida en las entradas individuales de la CRL. Las diferentes CRLs deben incluir la fecha en la cual se publicará la siguiente CRL, aunque si se han emitidos nuevas revocaciones antes de dicha fecha, se deberá publicar en ese momento.

5.5.2. Política de certificación y declaración de prácticas de certificación

Todas las CAs aceptadas en la federación andaluza deberán disponer de una Política de Certificación (CP) y una Declaración de Prácticas de Certificación (CPS), acordes a [RFC2527] y aceptadas formalmente por el órgano rector de la federación.

5.5.3. Validación TLS

A menos que se indique lo contrario en la especificación del perfil correspondiente, toda conexión entre dos componentes de la federación se realizarán usando TLS con validación mutua de los certificados usados en dicha conexión, tanto del que la inicia como del que responde.

5.5.4. Validacion de la firma XML

Se crearán y verificarán firmas XML para las siguientes construcciones SAML:

• Aserciones que contengan una declaración de autenticación SAML ( AuthenticationStatement) y, opcionalmente, diferentes declaraciones de atributo ( AttributeStatement) en respuesta a cualquier tipo de petición de autenticación, ya sea directa por XML, por medio de redirección Web o por cualquier otro procedimiento.

Se recomienda crear y verificar firmas XML para las siguientes construcciones SAML:

• Aserciones que contengan una declaración de atributo SAML ( AttributeStatement) en respuesta a una petición de atributos ( AttributeRequest).

6. Integración de aplicacionesAquí se ofrece una breve perspectiva de las formas en que se puede conseguir que el acceso a distintos tipos de aplicaciones Web sea controlado por un sistema de identidad federada, así como la información que cada una de éstas necesita que dicho sistema le proporcione.

En primer lugar, es importante clasificar las aplicaciones Web en distintas categorías atendiendo a sus posibilidades y las necesidades de controlar el acceso a las mismas.


6.1. Tipos de protección de aplicaciones Web

6.1.1. Páginas estáticas o aplicaciones que no contemplan control de acceso

El control de acceso en este caso debe hacerse a nivel de servidor Web o, en el caso de aplicaciones de las que disponemos del código fuente, podemos modificar el mismo para incluir llamadas al software de protección, si existe dicho software.

Casi todos los sistemas de federación disponen de un módulo para Apache u otros servidores Web, o para contenedores de servlets como Tomcat que permiten ejercer el control de acceso sin modificar la aplicación en absoluto.

Como ventaja principal, el no tener que modificar la aplicación. Entre sus inconvenientes, que exige la reconfiguración del servidor Web (algo no siempre conveniente en cierto entornos), y que permite menos flexibilidad, pues el control hay que hacerlo a nivel de rama de los documentos del servidor, típicamente, mientras que si es la propia aplicación la que controla, puede afinar más.

Este tipo de aplicaciones, al no tener previsto el concepto del usuario que accede, no necesitan recibir ningún atributo del sistema de identidad.

6.1.2. Aplicaciones que admiten plugins de autenticación/autorización

En este caso es posible que ya exista algún plugin disponible para el sistema que queramos utilizar. Si no, habrá que hacerlo, lo cual no suele ser muy complicado. Pueden considerarse dos casos típicos:

El sistema de identidad federada se configura a nivel de servidor Web para controlar el acceso a esta aplicación de forma que el plugin se limita a obtener los atributos necesarios.

No se configura el sistema de federación a nivel de servidor Web. El plugin se encarga de controlar el acceso invocando al sistema de identidad federada (usando su API) y de obtener los atributos.

En el primer caso el plugin obtiene el usuario y opcionalmente otros atributos (véase la sección 5.3 acerca de los mecanismos para ello). En el segundo caso se obtiene directamente usando el API de la federación. La forma en que se hace llegar el usuario a la aplicación ser· sencillo, dictado por el diseño de plugins de la aplicación, típicamente asignar el valor a una variable

6.1.3. Aplicaciones con mecanismos cerrados de autenticación/autorización

Podemos modificar el código fuente (con las opciones indicadas en el caso del plugin: usar la federación a nivel de servidor Web y dejar pasar aquí o controlar el acceso desde la aplicación). Si no queremos hacer esas modificaciones o no disponemos del fuente, podemos usar la funcionalidad de autorellenado de formularios, si el sistema de identidad federada dispone de ella (como es el caso de PAPI usando su módulo proxy de reescritura).

En este caso el propio sistema de identidad federada puede rellenar los campos de usuario y clave a partir de atributos recibidos del IdP. Como se explica en el siguiente apartado, es poco conveniente que la clave sea accesible en este punto.

Si modificamos el código fuente, prácticamente a todos los efectos es el mismo caso que el de los plugins. En el caso del autorrellenado de formularios, no se puede hacer más para pasar atributos.


6.1.4. Aplicaciones que son un interfaz o proxy para otro servicio que requiere autenticación

La más típica es el Webmail, aunque hay otras. Éstas pueden pertenecer a alguna de las dos categorías anteriores, pero presentan la particularidad de que la aplicación debe conectarse al servicio para el cual actúan de interfaz (un servidor IMAP en el caso del Webmail), al cual debe presentar las credenciales del usuario, normalmente userid/clave.

Por tanto parece que debemos usar un mecanismo que pueda proporcionar a la aplicación el usuario y la clave, sea como atributos recibidos del IdP o mediante el autorrrellenado de formularios. En el caso del Webmail los inconvenientes de esto (la clave llega al SP) no son tan graves porque normalmente éste es un servicio local, que no se presta a usuarios externos de la federación, y por tanto IdP y SP pertenecen al mismo dominio.

Sin embargo existe otra opción, y es que el servicio final implemente SASL para autenticación, que permite que la identidad autorizada sea diferente de la autenticada, esto es, en la fase de login se pueden presentar dos identificadores de usuario y la clave de uno de ellos, entrando con la identidad del otro. Por tanto los servidores que implementen SASL suelen tener forma de configurar este tipo de accesos (está disponible por ejemplo en los servidores POP/IMAP de UW y Dovecot). En este caso habría que modificar levemente el código fuente de la aplicación para que al conectar con el servicio final no use la clave del usuario sino el par usuario/clave que está configurado para entrar autorizado como cualquier otro usuario. Aquí existe un problema de seguridad obvio: si alguien consigue acceso al código fuente, y por tanto al usuario y clave de ese 'superusuario', puede suplantar la identidad de cualquier usuario en el servicio final (y posiblemente en otros)

6.2. Obtención de atributos

Consideramos aquí el caso de que el sistema de identidad federada se implementa a nivel de configuración del servidor Web, pues en caso de llamadas desde la aplicación a su API ésta dictará la forma de hacerlo.

Normalmente los valores de atributos estarán disponibles en forma de cabeceras HTTP (añadidas por el módulo de federación) o de variables PHP o mecanismos semejantes. El código fuente del plugin o el que modifiquemos de la aplicación tendrá que acceder a esta información.

6.3. Paso de atributos a la aplicación

En el caso de un plugin, el asunto es tan sencillo como rellenar desde éste las estructuras de datos o las tablas que la aplicación necesite, según las especificaciones de su sistema de plugins. Si por el contrario es necesario modificar el código fuente, el proceso es más o menos el mismo, aunque bastante más laborioso.

Sea cual sea el caso, en aplicaciones del tipo del Campus Andaluz Virtual puede que haya que tener en consideración algunos aspectos:

• En una aplicación de teleenseñanza instalada de forma normal, lo más habitual es que un usuario se registre la primera vez que entra (eligiendo su identificador de usuario y su clave), introduzca algunos datos personales (típicamente nombre y dirección de correo) y posiblemente algunos más. En algunas instituciones pueden haber hecho las adaptaciones necesarias para que sólo puedan acceder los usuarios autorizados, que se autentican contra el directorio corporativo. Esto exige algún tipo de provisión previa.

• En cuanto a que el usuario rellene sus datos, puede que tampoco se considere conveniente. Lo mejor parece ser que parte de estos se provisionen automáticamente, ya sea a priori o la primera vez que un usuario se conecta (no entramos aquí en el tema de lo mucho o poco flexibles que pueden ser estas aplicaciones en cuanto a los mecanismos de autenticación y/o provisión de los datos necesarios del usuario). Si esos datos se deben cargar en el momento del login, en el caso de


usuarios locales lo normal será cargarlos en la base de datos de la aplicación a partir del directorio o bases de datos corporativas. En el caso de usuarios remotos, estos datos se recibirán en forma de atributos a través de la federación..

En otros casos, como aplicaciones de Biblioteca, accesos a otros servicios como aparcamientos, alojamientos, etc. es posible que el sitio origen deba proporcionar determinados atributos para decidir qué tipo de acceso o servicios se le pueden proporcionar.

7. Casos de usoLos usos potenciales de este tipo de infraestructuras se extienden a todos los ámbitos de la cooperación interuniversitaria y de las universidades con otras entidades. En esta sección se incluye una descripción detallada de los casos de uso que se consideran de interés especial para la primera etapa del despliegue de la federación de identidad.

Para explorar los posibles casos de uso de una federación de identidades es conveniente clasificarlos de acuerdo con su área de aplicación. Esta es la idea de la siguiente clasificación, que proporciona un ejemplo de cada una de las categorías que propone:

● Para alumnos:○ Acceso a datos: E-learning (campus virtual).○ Acceso a software: Acceso a un entorno de aula virtual.○ Acceso a recursos físicos: Petición de libros en papel de una biblioteca.

● Para Personal de Administración y Servicios:

○ Acceso a datos: Wiki para grupos de trabajo.

○ Acceso a procesos: Emisión de tickets de incidencias.

○ Acceso a recursos físicos: Petición de material.

● Para Personal Docente e Investigador:

○ Acceso a datos: Documentos compartidos por grupos de investigación.

○ Acceso a documentación electrónica de biblioteca: Revistas e índices de impacto de las mismas.

○ Acceso a recursos software: Software científico para cálculo.

○ Acceso a recursos físicos: Instrumentos o sensores científicos.

7.1. Campus Andaluz Virtual

“El Campus Andaluz Virtual (CAV) es el elemento fundamental del proyecto Universidad Digital (Consejería de Innovación, Ciencia y Empresa de la Junta de Andalucía) que pretende conseguir una docencia completamente virtual y a distancia. El Campus Andaluz Virtual usa las plataformas de enseñanza virtual de todas las universidades andaluzas y es coordinado por el grupo UVAS.” (tomado de la página web del Campus Andaluz Virtual en septiembre de 2007)


En el CAV cada universidad participante ofrece varias asignaturas que se imparten con la plataforma de enseñanza virtual de la misma. Los alumnos de las asignaturas provienen de todas las universidades que participan en el CAV. El acceso de los alumnos a las plataformas de universidades distintas a la universidad en la que se han matriculado requiere la transferencia de datos entre universidades, pero es muy difícil transmitir con seguridad las claves de acceso, por lo que los alumnos tienen claves distintas en cada universidad con la que se relacionan.

La coordinación e intercambio de datos entre las universidades utiliza un portal común, actualmente situado en http://www.campusandaluzvirtual.es, donde cada universidad deposita los datos personales de sus alumnos y puede recoger los datos personales de los alumnos matriculados en las asignaturas que imparte. Se utiliza de forma parecida para agilizar el intercambio de actas con las calificaciones de los alumnos. También se utiliza para publicar los planes docentes de las asignaturas y otra información de carácter general del proyecto.

La utilización de una infraestructura de federación de identidades resulta de utilidad en dos aspectos diferentes del proyecto: las interacciones de los usuarios (alumnos, profesores, personal administrativo) con el portal y las interacciones de los alumnos con las plataformas de enseñanza virtual.

7.1.1. Objetivos

El objetivo fundamental de aplicar la federación de identidades al Campus Andaluz Virtual es conseguir que los alumnos puedan acceder a las plataformas de otras universidades con el mismo mecanismo que utilizan para acceder a los servicios de su propia universidad.

Utilizando la misma tecnología los alumnos, profesores y personal técnico y administrativo pueden acceder con mayor facilidad al portal del CAV usando su identificación y utilizar recursos específicos para cada uno.

7.1.2. Condiciones previas

Cada universidad debe configurar un proveedor de servicios (SP) para su plataforma de enseñanza virtual, especificando que proveedores de identidad miembros de la federación serán admitidos como IdP válidos. Ha de tenerse en cuenta que la federación puede crecer incluyendo otros miembros que no tengan nada que ver con el CAV, y que, por tanto, ha de mantenerse una lista de los IdP que serán reconocidos en el CAV.

7.1.3. Descripción detallada

Estos son los eventos que ocurren durante la identificación de un alumno para la utilización la plataforma de enseñanza virtual de una universidad participante en la federación.

1. El alumno accede a la página web de la plataforma donde se imparte la asignatura. Cómo consigue la dirección de esa página web depende de la universidad en que se matriculó. En el portal del CAV se encuentran las direcciones de las plataformas de todas las universidades participantes.

2. En esa página hay algún enlace, botón u otro artefacto que lleva al alumno hasta la página web del "Where are you from? (WAYF)". El WAYF muestra los proveedores de identidad que pueden ser utilizados por el alumno.

3. El alumno selecciona el proveedor de indentidad (IdP) que quiere utilizar, que será el que corresponda a la identidad que utiliza en su universidad, y es dirigido hacia la página de dicho proveedor.


4. En la página del IdP el alumno introduce su identificador y clave habitual y es dirigido automáticamente a la página web de la plataforma donde se imparte la asignatura. El navegador del alumno recibe un mensaje firmado criptográficamente que deberá entregar cuando se conecte a la plataforma donde se imparte la asignatura. Dicho mensaje demuestra la identidad del alumno.

5. Al conectarse (tras la redirección automática) a la página web de la plataforma donde se imparte la asignatura, el navegador entrega el mensaje a la plataforma, que conoce así la identidad del alumno y el IdP utilizado.

6. La plataforma comunica con el IdP a fin de obtener algunos datos más del alumno, por ejemplo los códigos de asignaturas del CAV en los que está matriculado, el correo electrónico del alumno, etc. Este intercambio de datos debe ajustarse a las normas de la federación.

7. La plataforma muestra al alumno las asignaturas que el alumno puede cursar y continua la interacción alumno/plataforma.

7.1.4. Cuestiones abiertas

El intercambio de datos que se produce en el penúltimo punto debe ser discutido en profundidad dentro del proyecto CAV; sin embargo, puede adelantarse que todas las asignaturas incluidas en el CAV reciben un código de 9 cifras que las identifica unívocamente y que podría utilizarse para que el IdP especificase a que asignaturas tiene derecho a acceder el alumno.

7.2. Transferencia de ficheros. Aplicación Consigna

Consigna es un servicio de intercambio de ficheros pesados entre usuarios de una institución o entre estos y usuarios externos. La determinación de si un usuario es interno se realiza por la dirección IP del ordenador que utiliza al acceder al servicio (se considera usuario local si ésta pertenece a la red interna de la institución). Cualquier usuario puede subir ficheros, pero estos sólo podrán ser descargados desde usuarios locales. Los ficheros subidos por usuarios locales pueden ser descargados por cualquier usuario. Esta simple política de uso permite que un usuario interno pueda intercambiar ficheros en ambas direcciones con cualquier usuario del mundo.

El uso descrito presenta dos problemas :

1. Cada vez más usuarios trabajan desde casa, cibercafés, etc. Por tanto cuando acceden desde ahí no se consideran usuarios internos.

2. Sería conveniente extender el servicio a usuarios de instituciones o grupos con los que hay relaciones de trabajo, colaboración, etc. Actualmente los ficheros que sube un usuario de un grupo externo no pueden ser bajados por otro usuario de su mismo grupo, por ejemplo.

El punto 1 se puede solucionar con cualquier sistema de autenticación. Para abordar el punto 2 es más adecuado un esquema de federación. En la solución que se propone cualquier usuario de la federación puede voluntariamente autenticarse y así disponer de los mismos permisos que un usuario interno.


Se parte de la base de que existe confianza en todos los usuarios de las instituciones federadas en el sentido de que no van a abusar del servicio. Si un usuario de una institución abusa del servicio (subiendo ficheros protegidos por derechos de autor, piratas, etc.) la institución origen del usuario, una vez informada del hecho, tomará las medidas adecuadas.


Debe quedar claro en los acuerdos que se establezcan que se exime a la institución que presta el servicio de los abusos cometidos por un usuario externo. Para ello se redactará un SLA (Service Level Agreement) que debe ser aceptado por las instituciones participantes.


No se obliga a realizar una autenticación para acceder a la aplicación, sino que el usuario accede a ella pinchando en un enlace ex-profeso. Al pinchar en el enlace, el navegador del usuario es enviado al servicio WAYF para seleccionar su institución de origen, a cuyo servicio de autenticación será redirigido. Tras presentar allí sus credenciales (normalmente usuario/clave) será redirigido de nuevo al servicio Consigna, el cual le reconocerá como usuario autenticado.

Un usuario autenticado podrá acceder los mismos servicios que los usuarios no autenticados (subida y bajada de ficheros), pero sin ninguna limitación, es decir:

● Podrán bajar cualquier fichero, aunque hubiera sido subido desde fuera de la red interna.

● Los ficheros que suba el usuario podrán ser bajados por cualquier usuario, se haya autenticado o no, se conecte o no desde la red interna.

7.2.3. Atributos

El único atributo que necesita Consigna de un usuario autenticado es su identificador (cabecera REMOTE_USER, habitualmente proveniente del atributo eduPersonPrincipalName), en la forma de NetID (usuario@dominioDeOrigen). Éste quedará asociado en el registro de actividades del usuario, al cual se accederá únicamente en el caso de que se detecten abusos, para pedir las responsabilidades adecuadas.

Este atributo es obligatorio, esto es, aunque el usuario se autentique en su institución origen, si dicho atributo no se presenta a la aplicación, no se considerará autenticado.


Si el servicio se monta en un proveedor sin usuarios propios, el control por IP no se utilizaría.

Habría que concretar más en detalle la política de uso, por ejemplo: los usuarios no autenticados sólo podrían bajar ficheros subidos por usuarios autenticados, y los ficheros que suban sólo podrían ser bajados por esos mismos usuarios.

7.3. Registro recíproco de usuarios de biblioteca

Los usuarios de las Universidades requieren acceso a los recursos de las bibliotecas, pero éstas solo permiten el acceso a usuarios registrados. Para una determinada biblioteca universitaria, se consideran usuarios registrados aquellos que disponen de las oportunas credenciales de la institución a la que pertenece la biblioteca. El uso de un esquema de federación se justifica por:

● La gran movilidad actual de los usuarios.

● La necesidad de los usuarios de una universidad de acceder los recursos de las bibliotecas en otras instituciones donde se desplazan.


7.3.1. Solución propuesta

Establecer mecanismos de federación entre las bibliotecas de las instituciones participantes, de tal manera que un usuario que esté autenticado en el IdP de su institución pueda acceder al SP de la biblioteca donde se encuentra y obtener credenciales que le permitan solicitar un recurso en la misma.


Se han establecido mecanismos de confianza entre las bibliotecas participantes y las instituciones de origen de los usuarios, de forma que aquéllas confían en que éstas solo autenticarán a usuarios que pueden hacer uso del servicio equivalente en una biblioteca de su institución de origen. Además, las bibliotecas participantes dispondrán de un mecanismo de registro de usuarios recíprocos en su sistema de gestión bibliotecaria (SGB).

Las bibliotecas participantes se comprometen a a registrar como usuarios recíprocos a aquellos que se autentiquen debidamente frente al IdP de su institución de origen y éste le indique que son usuarios válidos. Las instituciones participantes se comprometen a aplicar a los usuarios las mismas sanciones por el mal uso de los recursos en bibliotecas ajenas que las aplicadas en un caso igual en una biblioteca local. Debe quedar claro en los acuerdos que se establezcan que se compensará a la institución que presta el servicio de los abusos cometidos por un usuario externo, por medio de las medidas oportunas en la institución de origen. Para ello se redactará un SLA (Service Level Agreement) así como un acuerdo bilateral.


Los usuarios se autentican al llegar a la biblioteca de la institución receptora al solicitar el recurso:

1. El usuario se conecta al servicio de registro de usuarios recíprocos en la biblioteca de destino.

2. El sistema lo envía a un servicio WAYF para que seleccione su institución de origen.

3. El WAYF envía al navegador al IdP de la institución de origen.

4. El usuario presenta las credenciales necesarias para verificar su identidad.

5. El IdP envía al servicio de registro recíproco información de rol, estatus e identificar único del usuario.

6. El servicio de registro recíproco registra al usuario en el SGB como usuario recíproco válido.

El usuario obtiene el nivel de acceso a los recursos que tendría un usuario local a la institución del mismo tipo, es decir, que desempeñe un rol equivalente.

7.3.4. Atributos

● Identificador único (eduPersonPrincipalName, eduPersonTargetedID, schacPersonalUniqueID o schacPersonalUniqueCode).

● Nombre (displayName).

● Organización (schacHomeOrganization).

● Rol (eduPersonAffiliation o eduPersonPrimaryAffiliation).


● Estatus (schacUserStatus).


El atributo de estatus podría indicar el estatus de un usuario con respecto a un rol en particular. El identificador único podría ser el DNI o similar dentro de schacPersonalUniqueID o el código universitario dentro de schacPersonalUniqueCode, con un cierto significado en el contexto de las bibliotecas.

7.4. Provisión de cuentas

Uno de los servicios que puede ser necesario proporcionar a usuarios de una federación es el uso de ordenadores de otras instituciones. Es el caso del acceso (típicamente remoto) al entorno de aulas de docencia para usuarios del Campus Andaluz Virtual. Cuando el software o el material necesario para una asignatura no está disponible en la institución origen del alumno, debe proporcionarse dicho tipo de acceso. Ello requiere la creación de una cuenta para el alumno en el entorno de computación de la institución remota (IR). Otras opciones, como que el login del usuario pudiera validarse en cada acceso directamente contra la IR parecen poco factibles y, en todo caso, requerirían un estudio en mayor profundidad.

Los procesos de solicitud y creación de cuentas en los ordenadores se pueden simplificar, agilizar e incluso automatizar gracias a los mecanismos de seguridad y confianza que proporciona la federación, así como los datos del alumno que ésta puede proporcionar.


En una página Web integrada en un SP de la institución remota (y a cuyos ordenadores se pretende proporcionar acceso) se incorporará un enlace típicamente llamado 'Crear cuenta' tal que al pinchar en él se active el proceso de creación de la cuenta. Este proceso idealmente debería ser automático e inmediato, esto es, la cuenta debería estar disponible y lista para usarse a partir de ese momento o al menos en un plazo corto de tiempo.

Este proceso se puede producir de dos formas:

● La aplicación Web integrada en el SP se comunica con la aplicación de gestión de cuentas y le proporciona la información necesaria para su creación, a partir de los atributos que le proporciona el IdP. Si esto se hace mediante Web Services, se pueden aplicar en este punto mecanismos de federación.

● El navegador del usuario es redirigido a la aplicación de gestión de cuentas, a la que se le pasa (por ejemplo mediante parámetros GET) la información necesaria para la creación de la cuenta, usando los mecanismos de seguridad adecuados para que no puedan crearse cuentas replicando este tipo de URL.

El segundo mecanismo tiene la ventaja de que el usuario puede ser enviado a una página de la aplicación de gestión donde puede introducir la clave que desea tener.

Se propone que el nombre que se ponga a la cuenta sea la concatenación del nombre de usuario en la institución origen (típicamente la primera parte del EPPN) con un guión y la primera parte del dominio origen, por ejemplo 'luism-uco'. De esta forma se garantiza la unicidad, es cómodo para el usuario y facilita a los administradores de la institución remota la identificación de esas cuentas. Este nombre puede construirlo la aplicación de gestión de cuentas o la aplicación federada que invoca a ésta.



Los ordenadores de uso público de la IR deben estar configurados para autenticar contra un repositorio central (típicamente LDAP en el caso de Unix/Linux, Active Directory en el de Windows, etc.). Es muy conveniente además que disponga de alguna aplicación software de gestión de cuentas que centralice la creación y bajas de las mismas en todos los entornos operativos a los que pueda tener acceso el usuario, lleve un registro, etc.

En alguno de los atributos que se reciben del IdP debe indicarse el derecho del usuario a disponer de cuenta en los ordenadores, pues es algo que no debe proporcionarse de forma indiscriminada a todos los usuarios debido a:

● Las implicaciones de seguridad en los ordenadores

● Consumo de recursos en los mismos.

● Los inconvenientes de gestionar de un gran número de cuentas.

Se propone que el enlace para la creación de la cuenta se disponga dentro de alguna aplicación federada existente, y accesible sólo cuando ya se ha producido la autenticación en ésta. Normalmente se podrá acceder remotamente a entornos de escritorio o aplicaciones concretas de la institución remota. Las formas de acceso, etc. dependerán de la infraestructura de aulas docentes en cada sitio.

7.4.3. Atributos

En este caso de uso hay que prestar especial atención a la seguridad, pues se trata de proporcionar acceso a ordenadores de una institución. Es obligatorio el eduPersonPrincipalName para obtener el identificador de la cuenta. Como este caso de uso no documenta una aplicación concreta sino un servicio adicional, el resto de atributos necesarios habrá que enviarlos a la aplicación federada desde la que se activa la creación de cuentas. Entre estos atributos, obligatoriamente debe figurar uno (que ya se decidirá) que indique si se tiene derecho o no a una cuenta. Opcionalmente se pueden discutir otros que declaren a qué entorno/s operativo/s se debe tener acceso o incluso a qué material, aplicaciones concretas, etc. Por otro lado puede ser conveniente que se proporcionen más datos si así lo exige la aplicación de gestión de cuentas: nombre y apellidos, DNI, etc.

No creemos que sea necesario incluir atributos para aspectos relacionados con el consumo de recursos informáticos: cuota de disco, uso de CPU, etc.

7.5. Aula de informática virtual

El Aula de Informática Virtual forma parte de los proyectos impulsados en el marco del Campus Andaluz Virtual (CAV). En lineas generales, lo que se pretende es trasladar las aulas de informática que existen en las instalaciones de las universidades al entorno del CAV, donde no existe un espacio físico ni restricciones temporales. Por lo tanto, como indica su nombre, se trata de una "virtualización" de las aulas de informática y laboratorios docentes, y en consecuencia es necesario disponer de un control de acceso al aula mediante una identidad federada.

Los alumnos que cursan asignaturas del CAV debe poder acceder a todos los recursos necesarios para el aprendizaje de la materia de la que se ha matriculado. En muchos casos necesitan utilizar recursos informáticos que no siempre están disponibles en sus universidades (programas con licencia comercial, programas propios, diferentes sistemas operativos, etc.). Por lo tanto, se necesita un acceso remoto y un control de dichos recursos.


Como se puede deducir fácilmente, los problemas de control de acceso se agravan en el CAV y por lo tanto al utilización de una identidad federada es esencial en este entorno.

Además, esta tecnología puede facilitar el compartir recursos especiales, y por tanto, una mayor rentabilidad por su utilización por miembros de todas las universidades, haciendo posible que se puedan compartir fácilmente.


En el proyecto de Aula de Informática Virtual se establecen varias soluciones en el acceso a recursos informáticos, dependiendo de su naturaleza. Estos se pueden agrupar en dos tipos: acceso a remoto ordenadores físicos y acceso remoto a ordenadores virtuales. Ambas soluciones tienen dos fases de autenticación y autorización.

Una primera fase se ocupa del acceso remoto a los recursos, es decir, quién va a acceder al aula virtual y qué recursos (ordenadores virtuales o físicos) puede utilizar por su papel (perfil o rol) en el sistema. En este caso, sería necesario que el programa de control y gestión de recursos, también llamado "broker", se pueda federar con las identidades ofertadas en el CAV.

La segunda fase se trataría de que el usuario con permisos para acceder a un determinado ordenador del aula de informática virtual, se autentique en el mismo y acceda a sus aplicaciones. Esta fase puede ser realizada de manera automática a partir la información obtenida en la primera, siempre que sea posible técnicamente. De todas formas, la federación de la identidad y la autorización del puesto de trabajo sería muy importante en el CAV.


Para la utilización de un sistema federado de acceso remoto es necesario que dicho mecanismo se pueda federar. Además, es necesario que la institución dispongan de un aula de informática virtual con la que realizar la federación.

La universidad que presta el servicio establecerá una serie de norma de obligado cumplimiento y que debe acatar toda organización federada. Por lo que si un usuario de una institución abusa del servicio (subiendo ficheros protegidos por derechos de autor, piratas, etc.) la institución origen del usuario, una vez informada del hecho, tomará las medidas adecuadas. Debe quedar claro en los acuerdos que se establezcan que se exime a la institución que presta el servicio de los abusos cometidos por un usuario externo. Para ello se redactará un SLA (Service Level Agreement) así como un acuerdo bilateral.


El usuario va a acceder a aula de informática virtual mediante un navegador. Al pinchar en el enlace 'Login', el navegador del usuario es enviado al servicio WAYF para seleccionar su institución de origen, a cuyo servicio de autenticación será enviado de nuevo. Tras presentar allí sus credenciales (normalmente usuario/clave) será redirigido de nuevo al servicio Aula de Informática Virtual, el cual le reconocerá como usuario autenticado y le aplicará los premisos pertinentes.

Mediante la notificación de determinados atributos se puede perfilar el acceso de los usuarios a los ordenadores virtuales y a la aplicaciones. Por ejemplo, si un alumno está matriculado en una determinada asignatura el ordenador al que va a tener acceso a va tener instalada una determinada aplicación. Aunque, el caso más simple, el usuario tendrá acceso a un ordenador virtual (con sistema operativo Windows o Linux) en el que podrá utilizar todos los programas en él instalado.


7.5.4. Atributos

Los atributos van a ser definidos dependiendo de los servicios que van a ofrecer. Un atributo básico que necesita AIV de un usuario autenticado es su identificador (cabecera REMOTEUSER, habitualmente proveniente del atributo eduPersonPrincipalName), en la forma de NetID (usuario@dominioorigen). Éste quedará asociado en el registro de actividades del usuario, al cual se accederá únicamente en el caso de que se detecten abusos, para pedir las responsabilidades adecuadas. Este atributo es obligatorio, esto es, aunque el usuario se autentique en su institución origen, si dicho atributo no se presenta a la aplicación, no se considerará autenticado.

Otro atributo interesante puede ser la asignatura del CAV para ofrecer al alumno autenticado en la federación un ordenador virtual orientado a sus necesidades.

8. Referencias[EDUGAIN] eduGAIN Profiles and Implementation Guidelines[EDUPERSON] EduPerson Object Class Specification[RFC1630] RFC 1630 - Universal Resource Identifiers in WWW: A Unifying Syntax for the

Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web

[RFC1867] RFC 1867 - Form-based File Upload in HTML[RFC2527] RFC 2527 - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework[RFC2798] RFC 2798 - Definition of the inetOrgPerson LDAP Object Class[RFC3280] RFC 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

[RFC3377] RFC 3377 - Lightweight Directory Access Protocol (v3): Technical Specification

[RFC3548] RFC 3548 - The Base16, Base32, and Base64 Data Encodings

[SAML2B] Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0

[SAML2P] Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0

[SAMLMD] Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0[SCHAC] SCHAC Attribute Definitions For Individual Data [SCHIRIS] IRIS LDAP Schema. Generic objects for the IRIS community[X500] The Directory: Overview of concepts, models and services[X501] The Directory: Models[X509] The Directory: Authentication framework


ESPECIFICACIONES TÉCNICAS DEL ACCESO FEDERADO A LOS SISTEMAS DE ENSEÑANZA VIRTUAL DE...

Documents

Transcript of ESPECIFICACIONES TÉCNICAS DEL ACCESO FEDERADO A LOS SISTEMAS DE ENSEÑANZA VIRTUAL DE...