Integración de RadSec y DAMe sobre eduroam

Transcripción

1 Integración de RadSec y DAMe sobre Francisco J. Moreno 1, Manuel Gil Pérez 1, Gabriel López 1, Antonio F. Gómez Skarmeta 1, Sascha Neinert 2 1 Departamento de Ingeniería de la Información y las Comunicaciones, Universidad de Murcia {fran.moreno, mgilperez, gabilm, skarmeta}@um.es 2 Computing Centre, Universidad de Stuttgart sascha.neinert@rus.uni-stuttgart.de Abstract Actualmente la red está formada por una jerarquía de servidores que permite la movilidad de los usuarios a través de las organizaciones pertenecientes a esta federación. Este trabajo describe cómo esta jerarquía puede ser mejorada mediante el uso de propuestas como RadSec y DAMe, para ofrecer mayor seguridad en la conexión y en el acceso a servicios. Este trabajo muestra una integración de ambas propuestas sobre y un análisis de rendimiento para comprobar su viabilidad. Index Terms RadSec, DAMe,, federación. I. INTRODUCCIÓN Bajo el marco de TERENA se ha desplegado una de las mayores redes para roaming a nivel mundial, [1]. Esta red, orientada a instituciones relacionadas con la investigación y la educación, permite la movilidad de usuarios a través de más de 40 países a lo largo de 3 continentes, incluyendo China, Australia, Canadá y próximamente EEUU. Para conseguir esta cobertura, hace uso de una jerarquía distribuida de servidores a lo largo de cada zona geográfica, país e institución. De este modo, por ejemplo, cuando un usuario de la Universidad de Stuttgart realiza una solicitud de acceso a la red, durante su estancia en la Universidad de Calgary, en realidad lo que ocurre es que está solicitando acceso al servidor de la universidad visitada. Este servidor redirige la solicitud al nivel superior de la jerarquía, y así sucesivamente, hasta que se alcanza el servidor de la universidad local del usuario. En el caso de conexiones intercontinentales pueden requerirse hasta 6 servidores intermedios para una autenticación del usuario. Otro de los problemas conocidos de este tipo de jerarquías es que la comunicación entre servidores se basa en conexiones UDP, protegidas a través de secretos compartidos. Para ofrecer mayor seguridad en las comunicaciones y mayor control sobre el proceso de autenticación del usuario se han definido varias propuestas. Por un lado, RadSec [2] propone la extensión de para el soporte de conexiones TCP/TLS; además, ofrece mecanismos de descubrimiento de la organización local del usuario, lo que permite evitar recorrer toda la jerarquía. Por otro lado, el proyecto DAMe [3] define cómo puede extenderse la jerarquía de para permitir servicios de Single Sign On (SSO) y control de acceso avanzado basado en atributos del usuario. Este trabajo presenta cómo ambas soluciones pueden cooperar para ofrecer de un modo homogéneo todos los servicios de seguridad ofrecidos por ambas propuestas. Además, se presenta un análisis de rendimiento que permite comparar cómo el uso de canales TLS y mecanismos de descubrimiento pueden afectar al rendimiento de. Para describir esta integración, este trabajo está estructurado del siguiente modo. La Sección II describe la propuesta de DAMe, mientras que la Sección III hace una breve introducción de RadSec. La Sección IV describe la integración de ambas tecnologías, indicando los componentes y mecanismos de descubrimiento. La Sección V presenta el análisis de rendimiento y la Sección VI describe brevemente el trabajo relacionado. Finalmente, la Sección VII presenta algunas conclusiones y vías futuras. II. DAME La arquitectura general de DAMe se puede ver en la Figura 1, donde se muestra que es la iniciativa central de este proyecto. La principal idea que se pretende conseguir con DAMe es desplegar sobre el intercambio de credenciales de autorización y ofrecer mecanismos de SSO, ya desde el acceso a la red. Con DAMe, cualquier usuario será autenticado inicialmente usando, obteniendo un token SSO (edutoken) que será utilizado posteriormente para acceder a otros recursos de la federación. Resource Access Policy Organización Visitada Servidor IdP Fig. 1. edugain BE Autenticación Autorización edugain BE Arquitectura general de DAMe Organización Local Servidor IdP Attribute Release Policy Respecto al proceso de autorización, esta arquitectura hace uso de edugain [4] para ofrecer gestión de credenciales a nivel de federación sobre. De este modo, permite utilizar el sistema como back-end de control de acceso a la federación, mientras que cada organización de forma local

2 Organización Visitada Organización Local Usuario NAP RADSEC RADSEC edugain BE idp AuthN Attrib. /MDS Descubrimiento Dinámico Prueba de Identidad Autenticación del Usuario AuthN response AuthNStat. AuthN response Generación del token handle (+handle) (+handle) (+handle) EAP-Success (+propiedades) Autorización de Red PEAP SOAP Federation specific EAPOL TLS EAP /HTTPS Fig. 2. Proceso de autenticación en DAMe haciendo uso de RadSec puede hacer uso de sus propios métodos de autenticación y autorización. Para hacer uso de edugain se deben desplegar los Bridging Elements (BE) correspondientes para la traducción de mensajes de autorización, autenticación y petición de atributos. En el escenario de la Figura 1 mostramos dos organizaciones. Una es la organización local del usuario, que aloja su Proveedor de Identidad (IdP); por lo tanto, define como mínimo dos entidades, una autoridad de autenticación y una autoridad de atributos a la que solicitar información sobre dicho usuario. Además, es necesaria la existencia de un servidor [5] conectado a para la fase de autenticación del usuario. En la organización destino aparecen tanto un servidor conectado a, igual que en la organización local, un BE de edugain que se encargará de traducir los mensajes recibidos a formato interno, y una entidad llamada Policy Decision Point (PDP) que se encarga de tomar la decisión de autorización en base a los atributos recibidos de la organización local. A. Autenticación de red En DAMe esta fase se basa en para poder autenticar al usuario a nivel de red, utilizando para ello la jerarquía de servidores ya establecida. La extensión que se añade sobre este proceso consiste en que el servidor de autenticación de la organización local pueda solicitar a su BE un token (edutoken), que recibirá el usuario, con el que podrá acceder a otros servicios mediante SSO. Para evitar un posible robo del token por un usuario malintencionado, se debe proteger tanto el envío como el almacenamiento en el dispositivo del usuario. B. Distribución del token SSO de autenticación Para establecer un canal seguro entre el usuario y el servidor de autenticación, para el envío del token, podemos hacer uso de métodos EAP, como por ejemplo TTLS [6] o PEAP [7]. El token se almacena en el dispositivo del usuario de forma segura, para que luego pueda ser utilizado por los servicios a nivel de aplicación. C. Fase de autorización Una vez el usuario ha obtenido el token de autenticación, la organización visitada debe conocer las capacidades del usuario para decidir a qué servicios puede acceder, que características tendrá su conexión, etc. Para ello se establece una segunda fase en la que se realiza una consulta de los atributos del usuario, obtenidos desde su organización local a través de edugain, que serán enviados al PDP para tomar la decisión de autorizar o no al usuario en base a esos atributos. DAMe se basa en el uso de tecnologías estándar, como SAML [8] o XACML [9]. Una descripción más detallada de este proceso puede encontrarse en [10]. III. RADSEC RadSec [2] ofrece una solución para implementar haciendo uso de conexiones TCP/TLS, ayudando a que las transferencias de información de autenticación y autorización sean más eficientes y seguras.

3 En se hace uso de una jerarquía tradicional, descrita anteriormente, donde todos los mensajes de autenticación y autorización recorren la jerarquía desde el servidor remoto al local. Todo este intercambio, que se hace mediante UDP y usando un cifrado basado en secretos compartidos, se pretende cambiar, a nivel organizativo, por una conexión directa entre ambos servidores y una arquitectura de clave pública para su seguridad. La principal idea de RadSec, además de establecer seguridad y eficiencia en la comunicación, es evitar que se deba hacer uso de toda la jerarquía de para la comunicación entre la organización local y visitada (como queda representado en la Figura 2). Para ello, se establece un canal directo entre los servidores RadSec remoto y local, estableciendo todo el intercambio de autorización y autenticación a través de dicho canal. Para que esta conexión pueda llevarse a cabo mediante TCP/TLS deben existir una serie de elementos indispensables entre ambos servidores RadSec: Certificado de clave pública para el servidor que soporta RadSec y su correspondiente clave privada. Autoridad de certificación (CA) emisora. Es necesario un modelo de confianza entre ambas organizaciones, por ejemplo mediante una jerarquía de certificación común o a través de confianza mutua. Servicios de validación y descubrimiento. Finalmente, hay que tener en cuenta las características de autodescubrimiento que se plantean en RadSec, ya que la configuración estática de los servidores conocidos plantea un serio problema de escalabilidad [11]. Se han propuesto varias alternativas basadas en [12], Sec [13] o publicación de metadatos, que serán descritas en la siguiente sección. Actualmente la solución más utilizada es Free [14], que no tiene aún soporte para RadSec, por lo que será necesario hacer uso de entidades proxy, como radsecproxy [16], para desplegar esta solución. IV. ARQUITECTURA Y DESPLIEGUE Entre las distintas posibilidades de integración disponibles nos encontramos con Radiator [15], un software stand-alone de que lleva integrado RadSec de forma nativa. Otra opción, por la que finalmente hemos optado, es la instalación de servidores radsecproxy que actúen como proxys entre los servidores Free. La arquitectura propuesta con RadSec quedaría como se puede ver en la Figura 2, donde los principales elementos de la arquitectura son: Supplicant: Software instalado en el dispositivo del usuario para conectarse a la red. También debe permitir la creación de un canal seguro entre el usuario y el servidor de su organización local. NAP: Punto de acceso que provee al usuario de acceso a la red. Remoto: Responsable de redirigir las peticiones de autenticación del usuario hacia el servidor RadSec de su organización. RadSec Remoto: Responsable de descubrir el servicio RadSec de la organización local del usuario y de enviar las peticiones recibidas del servidor hacia éste. Servidor /MDS: Para el descubrimiento de la organización local, será necesario definir el mecanismo a utilizar, o MDS. Los requerimientos de estos servicios se describirán más adelante. RadSec Local: Servidor RadSec de la organización local que recibe las peticiones de conexión del usuario desde el servidor RadSec Remoto. Estas peticiones serán reenviadas al servidor Local para que realice la autenticación del usuario. Local: En base a la petición de autenticación recibida realiza la autenticación correspondiente y solicita al IdP, a través del BE Local, una sentencia SAML (edutoken) que será enviado al usuario y con el que podrá comenzar futuras sesiones de SSO. BE Local: Encargado de traducir la solicitud del servidor Local a la tecnología utilizada por el IdP. Con la información recibida de éste, el BE Local creará el edutoken que le será enviado al usuario, en función de la información recibida del IdP. IdP: Entidad que maneja los atributos y las identidades de los usuarios, la cual recibe consultas de autenticación desde el BE Local. También recibe peticiones de atributos de los usuarios durante la fase de autorización. El IdP puede estar basado en diferentes tecnologías como Shibboleth [17], PAPI [18], etc. La interacción entre las entidades añadidas para la integración de RadSec en DAMe queda reflejada en la Figura 2. A continuación, mostramos paso a paso el proceso completo que seguiría una interacción común de autenticación en DAMe con RadSec. A. Autenticación Inicialmente, el Supplicant del usuario hace una petición de acceso a la red al NAP y, como en un esquema común, éste envía un mensaje Access-Request al servidor de la organización visitada. En este punto, el servidor Remoto, que tendrá configurado el servidor RadSec de su organización como proxy, le reenviará el mensaje mediante un mensaje UDP común y será el proxy RadSec el encargado de transmitirlo a la organización local a través de un canal seguro entre ambas organizaciones. El servidor RadSec Remoto procede con el descubrimiento del servidor RadSec de la organización local. El proceso de descubrimiento dinámico de entidades RadSec queda explicado en el siguiente subapartado. Una vez descubierto el servidor RadSec de la organización local, se procede a crear un canal seguro entre los dos servidores haciendo uso de TLS. A partir de este momento, todos los mensajes se intercambiarán de manera segura. Una vez que el mensaje de autenticación llega al servidor RadSec Local, éste se encontrará configurado para retransmi-

4 tirlo al servidor de su organización, que procederá con el proceso de autenticación. Para dicha autenticación se sigue el funcionamiento común de DAMe, realizando una petición del token de autenticación (eduttoken) al IdP local, a través del BE Local. Una vez tomada la decisión de autenticación, se procede a enviar el mensaje desde la organización local a la visitada. En este caso, el servidor Local, que tendrá configurado el servidor RadSec de su organización como proxy, le enviará el mensaje para que sea reenviado a través del canal seguro TLS. Una vez que el servidor RadSec Remoto recibe dicho mensaje, lo reenvía a su servidor que será el encargado de hacerlo llegar al punto de acceso desde donde el usuario está tratando conectarse, y que le dará el permiso para poder acceder a la red. B. Transmisión del token y fase de autorización Una vez que el servidor Local obtiene el token SSO, lo envía a través del canal seguro y éste se almacena en el dispositivo del usuario, tal y como se comentó anteriormente. Respecto a la fase de autorización, no se ve afectada por la integración de RadSec, por lo que se sigue el proceso normal que se realiza en DAMe. Organización Local RadSec Fig. 3. NREN C. Autodescubrimiento TLS MDS NREN RadSec Descubrimiento dinámico en RadSec Organización Visitada Una vez definida la integración de los servidores RadSec en DAMe, se debe plantear una solución al problema del descubrimiento de los puntos de autenticación del resto de organizaciones. En nuestro caso estudiamos dos posibles vías: haciendo uso del servicio de descubrimiento de nombres ; y mediante el uso de un servicio común de metadatos (MDS) siguiendo la propuesta de edugain. 1) Autodescubrimiento usando : Para llevar a cabo este método, la organización local debe anunciar, mediante una entrada SRV en su servidor, el servidor RadSec que estará esperando conexiones entrantes de otras organizaciones. El servidor RadSec Remoto hará una consulta preguntando por el servicio radsec. tcp dentro del dominio local, como se establece en [2]. Una vez conocido el servidor RadSec de la otra organización, se procede al establecimiento del canal seguro, NAP haciendo uso de los certificados que tanto el servidor de la organización visitada como el de la local tienen. El uso de Sec en RadSec también se ha propuesto, aunque queda fuera del ámbito de este trabajo y se planteará como trabajo futuro. En la Figura 3 puede verse un esquema de la interacción del en el esquema de DAMe. 2) Autodescubrimiento usando edugain MDS: En este otro caso se ha usado la estructura de metadatos ofrecida por edugain para hacer el anuncio de servicios. <md:entitydescriptor ID=... entityid=... > <md:idpssodescriptor ID= USTUTT RADSEC > <md:singlesignonservice Location= radsec(*)://ksat.rus.uni stuttgart.de:2083 /> </md:idpssodescriptor> <md:organization> <md:extensions> <egmd:hlpattern egmd:matchingalgo= urn:..:metadata:exact > uni stuttgart.de </egmd:hlpattern> </md:extensions> </md:organization> </md:entitydescriptor> Listing 1. Ejemplo de fichero MDS Será la organización local la que haga uso de un repositorio de metadatos para anunciar su servidor RadSec, y será el cliente (en nuestro caso el servidor RadSec Remoto) el encargado de preguntar a dicho repositorio por el servidor que desea localizar. Esta solución tiene algunas consideraciones de seguridad a ser tomadas en cuenta, como por ejemplo: El servidor remoto debe asegurarse que pregunta al MDS correcto, haciendo uso de los certificados correspondientes. El MDS debe validar la información que anuncia. En el Listado 1 mostramos un ejemplo de la información almacenada en el MDS, que servirá para el descubrimiento del servicio de RadSec en la organización local. En la Figura 3 se ve también la integración del servidor MDS para la obtención de la información necesaria por parte de la organización visitada. V. MEDIDAS DE RENDIMIENTO En esta sección detallamos la viabilidad a la hora de introducir RadSec en la arquitectura actual de DAMe. Elemento Hardware Software Organización Visitada (Universidad de Murcia) Suppplicant Pentium M 1.60 GHz 512MB RAM WPASupplicant NAP Linksys WRT54G - AMD Opteron 246 Free RadSec 1GB RAM radsecproxy Organización Local (Universidad de Stuttgart) BIND P2.1 MDS Pentium Dual 2GHz Apache 2.2/mod ssl RadSec 2GB RAM radsecproxy Free BE Local Pentium IV 3GHz Tomcat IdP 1GB RAM Shibboleth 1.3 OpenLDAP TABLE I ELEMENTOS HARDWARE Y SOFTWARE DEL TESTBED

5 Autenticación estándar Autenticación estándar Autenticación extendida () ( + RadSec) ( + RadSec + edutoken) 2082 / / /MDS Autenticación Shibboleth Obtener edutoken 81 / TABLE II MEDIANA DE LOS TIEMPOS OBTENIDOS PARA LAS MEDIDAS DE RENDIMIENTO (MS) Para ello, se ha utilizado la infraestructura desplegada en DAMe, incluyendo los servicios que tanto y edugain proporcionan para, respectivamente, autenticar y autorizar a los usuarios de la federación. Como hemos comentado anteriormente, esta arquitectura se ha extendido añadiendo únicamente dos servidores RadSec (uno por organización). Las pruebas realizadas se han llevado a cabo entre la Universidad de Murcia (organización visitada donde el usuario quiere conectarse a la red) y la Universidad de Stuttgart (organización local a la que el usuario pertenece). En la Tabla I mostramos los detalles hardware y software de los elementos utilizados para desplegar el escenario explicado anteriormente (ver Figura 2). El sistema operativo utilizado en todos los componentes es una Ubuntu Kernel , a excepción del BE Local/IdP que es un Windows 2003 SP2. Todas las muestras de tiempo obtenidas en esta sección, medidas en milisegundos, se han realizado ejecutando 105 veces la prueba correspondiente de forma secuencial. Las pruebas que se han realizado, como se puede ver en la Tabla II (una prueba por columna), son las siguientes: Autenticación estándar/básica en. Autenticación estándar en a través de los servidores RadSec. Autenticación extendida en, a través de los servidores RadSec, incluyendo la generación del token SSO (edutoken) por parte del IdP de Stuttgart. En este último caso hemos realizado dos pruebas diferentes, según el método de autodescubrimiento utilizado por el RadSec Remoto para localizar el servidor RadSec Local de la Universidad de Stuttgart: mediante o MDS. Ambos servicios, como podemos ver en la Tabla I, han sido instalados en la organización local (Universidad de Stuttgart). En la Tabla II se muestran las medianas de los tiempos obtenidos para cada una de las pruebas anteriores. En la primera columna se visualizan los tiempos para una autenticación estándar con. En este caso, hemos realizado dos pruebas: Estableciendo un canal PEAP con Stuttgart usando toda la jerarquía de, compuesta por 5 servidores en total, obteniendo un tiempo de 1498ms. Viendo estos tiempos podemos ver cómo la utilización de RadSec (segunda columna) es ligeramente mejor, 1319ms frente a 1498ms, ya que se evita tener que recorrer toda la jerarquía de. Estableciendo el canal PEAP directamente entre los dos servidores de ambas universidades, obteniendo un tiempo de 753ms. Esta prueba se ha realizado para comprobar qué diferencia de tiempo hay entre utilizar RadSec o no, sin tener en cuenta la jerarquía de, ya que RadSec no la utiliza. En este caso, podemos ver que la introducción de RadSec supone un incremento de 753ms a 1319ms; es decir, un 75% de sobrecarga. Como primera conclusión de estos tiempos podemos afirmar que, aunque la introducción de RadSec supone un incremento considerable, los tiempos en DAMe son incluso ligeramente mejores (sobre el 13%, de 1498ms a 1319ms). Esta mejoría se debe a que ya no es necesario tener que recorrer toda la jerarquía establecida en. La última columna de la Tabla II muestra el tiempo obtenido en la autenticación, con soporte RadSec, incluyendo la generación del edutoken, como se realiza en DAMe. En esta prueba, los tiempos se dividen dependiendo del tipo de autodescubrimiento utilizado. Haciendo uso de un servicio obtenemos un tiempo total de 2082ms, mientras que la utilización de MDS supone un tiempo de 2389ms. Podemos comprobar que ambos tiempos son asumibles por parte del usuario, aunque la diferencia entre ambos métodos de autodescubrimiento es un factor bastante significativo (de 81ms para el a 388ms para el caso del MDS). milisegundos estándar Fig MDS AuthN con RadSec AuthN Shibboleth Obtener edutoken Descubrimiento (/MDS) + RadSec Tiempos de autenticación con/sin RadSec La Figura 4 muestra gráficamente los mismos tiempos que se incluyen en la Tabla II, para así poder compararlos de forma más intuitiva. En este caso podemos distinguir claramente el incremento que supone la utilización del autodescubrimiento por y MDS. Finalmente, todos los tiempos obtenidos utilizando el autodescubrimiento mediante se ilustran en la Figura 5.

6 ms Fig. 5. percentil Percentil de la autenticación con RadSec () Todos los tiempos que hemos presentado en esta sección están relacionados con la fase de autenticación que se realiza a través de. Para el proceso completo de autenticación y autorización, como se establece en DAMe, faltaría incluir a estos tiempos la última fase de autorización por red. Este tiempo, también sobre DAMe, ha sido calculado en [19], obteniendo 531ms. Por tanto, si sumamos este tiempo al obtenido en esta sección para la fase de autenticación (2082ms, para el caso de ), tendríamos un tiempo total de 2613ms. Este tiempo sigue siendo asumible por el usuario final para obtener la conexión de red solicitada en la organización visitada. VI. TRABAJO RELACIONADO No existen trabajos realizados sobre esta temática que incluyan una integración completa de RadSec en una arquitectura definida junto con medidas de rendimiento. Este trabajo se basa principalmente en la documentación generada en GÈANT [20][21], donde se presentan diferentes alternativas a la integración de RadSec en. VII. CONCLUSIONES Y TRABAJO FUTURO Este trabajo presenta una propuesta de integración de RadSec y DAMe sobre una red en producción como es, por lo que se ofrece una mejora significativa sobre los problemas de seguridad relacionados con. Para comprobar la viabilidad de la propuesta se ha realizado un análisis del rendimiento sobre un escenario real, entre dos organizaciones conectadas a la federación. El análisis muestra que la integración de RadSec mejora los tiempos de comunicación sobre el uso tradicional de la jerarquía, y que, además, la integración con DAMe supone unos tiempos asumibles por el usuario, teniendo en cuenta que además de mayor seguridad en las comunicaciones, podrá hacer uso de mecanismos avanzados de autorización y de SSO. Como trabajo futuro se plantea la integración del escenario con mecanismos NEA para el control de acceso basado en atributos del dispositivo del usuario, y la integración del proceso de intercambio de atributos con RadSec. REFERENCES [1] K. Wierenga et al. Deliverable DJ5.1.4: Inter-NREN Roaming Architecture. Description and Development Items. GN2 JRA5, GÉANT 2, Septiembre [2] S. Winter, M. McCauley, S. Veenas and K. Wierenga. TLS encryption for. IETF Internet-Draft 06, Marzo [3] DAMe Project. Website: [4] D.R. López, J. Macías, M. Molina, J. Rauschenbach, A. Solberg and M. Stanica. Deliverable DJ.5.2.3,2: Best Practices Guide - AAI Cookbook - Second Edition. GN2 JRA5, GÉANT2, Marzo [5] C. Rigney, S. Willens, A. Rubens and W. Simpson. Remote Authentication Dial in User Service (). RFC 2865, Junio [6] P. Funk and S. Blake-Wilson. EAP Tunneled TLS Authentication Protocol (EAP-TTLS). IETF Internet-Draft 05, Julio [7] A. Palekar, D. Simon, J. Salowey, H. Zhou, G. Zorn and S. Josefsson. Protected EAP protocol (PEAP) Version 2. IETF Internet-Draft 10, Octubre [8] E. Maler, P. Mishra and R. Mishra (Ed.). Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1. OASIS Standard, Septiembre [9] T. Moses (Ed.). extensible Access Control Markup Language (XACML) Version 2.0. OASIS Standard, Febrero [10] O. Cánovas, M. Sánchez, G. López, R. del Campo, S. Neinert, J. Rauschenbach and I. Thomson. Deliverable DJ.5.3.2: Architecture for Unified SSO. GN2 JRA5, GÈANT2, Mayo [11] T. Lenggenhager et al. Deliverable DJ5.4.1,2: Advanced Technologies Overview, Second Edition. GN2 JRA5, GÈANT2, Febrero [12] S. Winter and M. McCauley. NAI-based Dynamic Peer Discovery for over TLS and DTLS. IETF Internet-Draft 02, Marzo [13] Extensions (dnsext), IETF Network Working Group. Website: [14] The Free Project. Website: [15] Radiator Project. Website: [16] radsecproxy. Website: [17] T. Scavo and S. Cantor. Shibboleth Architecture: Technical Overview. Internet2 Working Draft 02, Junio [18] D.R. López and R. Castro-Rojo. Ubiquitous Internet Access Control: The PAPI System. Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA), pp , [19] M. Sánchez, G. López, O. Cánovas, A.F. Gómez-Skarmeta. Performance Analysis of a Cross-layer SSO Mechanism for a Roaming Infrastructure. Journal of Network and Computer Applications, 32(4): , Febrero [20] S. Winter, T. Wolniewicz and I. Thomson. Deliverable DJ3.1.1: RadSec Standardisation and Definition of Extensions. GN3 JRA3, GÈANT3, Noviembre [21] S. Winter, M. Milinovic and I. Thomson. Deliverable DS5.4.1: Report on RadSec Integration. GN2 SA5, GÈANT2, Julio AGRADECIMIENTOS Este trabajo ha sido parcialmente financiado por el proyecto MULTIGIGABIT EUROPEAN ACADEMIC NETWORK (FP7-INFRASTRUCTURES ), y el programa de excelencia para grupos de investigación de la Fundación Séneca (04552/GERM/06).