En uno de nuestros proyectos nos hemos encontrado con la situación de tener que unir dos federaciones PAPI, permitiendo que personas que pertenezcan a una federación puedan acceder a los recursos federados de otra federación.
La solución que hemos ideado ha llevado al desarrollo de un nuevo elemento en php que implementa el protocolo PAPI, al cual le hemos denominado ASProxy.
Este elemento permite conectar dos GPoAs, cada uno de una federación diferente. Para la federación que protege los recursos, el ASProxy actúa como un AS normal, pero para el GPoA de la federación a la que pertenece el usuario, el ASProxy se comporta como un PoA.
Cuando un ASProxy recibe un mensaje ATTREQ de un GPoA, traduce esa petición en un mensaje CHECK, almacenando en la sesión información necesaria para cuando esa petición sea contestada. En esa petición ATTREQ se envíará el parámetro PAPIHLI con el valor del AS de la federación 2 al que pertenece, pudiendo así evitar el paso de que el usuario tenga que seleccionar de nuevo en un WAYF a qué institución pertenece.
Cuando a un ASProxy le llega un mensaje CHECKED de respuesta proveniente del GPoA de la federación 2, éste deberá transformar este mensaje, descifrándolo con la clave pública del GPoA de la federación 2, modificando la información necesaria y cifrándolo con su clave privada para que el GPoA de la federación 1 pueda comprender la respuesta.
Esta será un mensaje CHECKED de tipo AS->GPoA, distinto del recibido anteriormente, de tipo GPoA->PoA.
Como una extensión futura a este componente, estamos pensando la forma más adecuada de enviar, dentro de la aserción obtenida, el AS de la federación 2 donde el usuario se ha autenticado para que así, en la federación 1, puedan realizar filtros con esta información.
Desde PRiSE seguiremos informando de cómo evoluciona este componente.
Recientemente hemos finalizado un proyecto que hemos llevado a cabo con la Universidad de Sevilla para actualizar y migrar a nuevas versiones su actual despliegue de PAPI en sus instalaciones.
Gracias a este proyecto y su apoyo hemos podido desarrollar dos nuevos componentes PAPI con licencia GPL. Estos son los siguientes:
- PHP easyGPoA: es un GPoA desarrollado 100% en PHP y muy sencillo. El objetivo es proveer de un componente de este tipo de funcionalidad para aquellos casos que no requieren una complejidad elevada. Sus características principales son:
- GPoA 100% funcional desarrollado en PHP.
- Permite definir qué Proveedores de Identidad PAPI admite.
- Filtro de atributos por PoA, permitiendo definir qué atributos se deben mandar a cada uno de los PoAs en los que confía.
- Where Are You From? o selector de Proveedor de Identidad PAPI.
- PHP icGPoA: es una re-implementación completa del icGPoA desarrollado en PHP de manera que tengamos uno modular que sea más fácil de mantener entre todos los usuarios de este componente. De esta forma, las adaptaciones locales están separadas del código principal, por lo que a partir de ahora será más fácil mantener nuestro icGPoA a la última versión oficial.
Todavía no hay mucha documentación de ambos proyectos, y es que estamos trabajando en la nueva web de PAPI donde estamos escribiendo ya cómo instalarlos y cómo configurarlos, además de mucha más información del resto de los componentes.
Si quieres ir probándolos, puedes descargarlos utilizando los siguientes repositorios Mercurial:
- hg clone http://www.prise.es/hg/papi-easygpoa
- hg clone http://www.prise.es/hg/papi-icgpoa
Hemos añadido una breve descripción del proyecto que hemos realizado en los pasados meses con la Consejería de Economía, Innovación y Ciencia de la Junta de Andalucía, junto con la empresa Opentia.
En esta ocasión hemos diseñado y desarrollado un Servicio de Token de Seguridad (STS) conformes al estándar WS-Trust 1.4 para dicha Consejería. El objetivo era permitir la transmisión de información entre aplicaciones de dicha consejería a través de SAML 2 en un escenario donde no existía un Proveedor de Identidad único.
De esta forma, las aplicaciones utilizan SAML 2 para transmitir información entre ellas para lo cual hemos tenido que definir 5 tipo de perfiles en el proyecto, uno por cada tipo de autenticación que nos encontramos en dicha Consejería:
- Perfil nombre de usuario y contraseña
- Perfil certificado digital X.509
- Perfil certificado digital X.509 procesado por @firma
- Perfil NIF y localizador
- Perfil NIF
Como vemos, no es necesario que haya desplegado un Proveedor de identidad SAML 2 o un Single Sign-On para que las aplicaciones de una empresa u organismo disfruten de las ventajas de trabajar con dicha tecnología.
Hace poco descubri una aplicación muy interesante para facebook: Scan for privacy .
Ésta realiza un análisis de las características que ofrece facebook para compartir tus datos personales con el resto del mundo.
Una vez realizado este análisis, la aplicación hace recomendaciones sobre qué debemos modificar en la configuración de nuestros perfiles para mejorar la privacidad y la protección de nuestros datos personales.
Una de las mejores características de esta aplicación es que no almacena ni comparte la información analizada, ya que está desarrollada para que se ejecute sólo en tu navegador.
Desde PRiSE recomendamos que revises las preferencias de privacidad de tus cuentas en redes sociales: ¡Hay que estar seguros de lo que compartimos sobre nosotros en la red!.
Actualización
Existe otra aplicación similar , la denominada SaveFace. Ésta funciona de forma similar a Scan for Privacy, con la salvedad de que este último directamente te protege la cuenta de facebook, sin pedirte confirmación ni mostrarte tu estado inicial.
Esto podría ser un aspecto a mejorar por parte de SaveFace, ya que quizás sea más educativo que sepamos qué es lo que no tenemos adecuado en nuestro perfil y vulnera la privacidad de nuestros datos.
El 20 de Abril del 2009 fue un mal día para las organizaciones (y el software libre en general, aunque es mi opinión personal y ya hablaré de esto en otro momento) que utilizaban OpenSSO: Oracle decidió comprar Sun Microsystems.
Uno de los problemas que han surgido a raíz de dicha compra es el estado “incierto” que están sufriendo aquellos usuarios de OpenSSO. ¿Ha dejado de ser un proyecto libre? O mejor dicho, ¿ha dejado de ser un proyecto en activo?
Ahora hay que registrarse en Oracle y solicitar una cuenta de cliente con ellos para descargarlo, mientras que los agentes de política (los módulos de openSSO que se instalaban en un servidor web para proteger una zona) han desaparecido misteriosamente sin comunicar nada en su página web.
Como muchos de sus usuarios están evaluando alternativas para migrar a otro producto, nosotros queremos proponerles que migren a PAPI. Gracias a OpenSSO2PAPI podrán migrar a una infraestructura basada en PAPI sin necesidad de cambiar la tecnología que usaban para proteger las aplicaciones.
OpenSSO2PAPI es un software a través del cual PAPI puede ofrecer la API que OpenSSO provee para gestionar la cesión de datos de identidad y atributos a las aplicaciones que estén protegidas con dicha tecnología, implementando el comportamiento y las APIs que dichas aplicaciones esperan.
Podemos dividir la arquitectura de OpenSSO en dos grandes bloques:
- Páginas de interacción con el usuario, como la pantalla de Login o de Logout para el usuario. Normalmente se encuentra en el directorio /opensso/UI/.
- API para consultar servicios web tipo REST y SOAP, encontrándose bajo el directorio /opensso/identity/.
Hemos implementado en Opensso2PAPI un conjunto de pantallas y APIs tipo REST y hemos comprobado que funciona perfectamente con aplicaciones protegidas con OpenSSO.
La idea es que OpenSSO2PAPI utiliza un PoA (utilizando phpPoA) para obtener de una infraestructura PAPI, o de un Servidor de autenticación en concreto a través del parámetro PAPIHLI, la identidad del usuario y sus atributos. De esta forma, es como si el OpenSSO delegara en PAPI la gestión de la identidad del usuario.
Cambiando tan sólo las URLs que tenemos definidas en nuestras aplicaciones, la cual hemos protegido con OpenSSO, por la nueva dirección donde está desplegado OpenSSO2PAPI, habremos migrado a PAPI sin necesidad de realizar cambios en dichas aplicaciones con un coste elevado.
Los que nos movemos en el mundo tecnológico y hace años aterrizamos en la privacidad y la protección de datos, echábamos de menos algún tipo de certificación oficial. En cierta manera, una ayuda para justificar que tu trabajo se basaba en el trabajo bien hecho, en las buenas prácticas heredadas de otras certificaciones, de la experiencia aprendida tras rodearte de grandes profesionales.
Hace un año empezó un movimiento nacional… bueno, dos. Pese a que al principio parecía que se iba a crear una organización nacional para acreditar a los profesionales de la Protección de Datos, finalmente fueron dos las creadas.
Las dos organizaciones de las que hablamos son:
- Data Privacity Institute (DPI) dentro del ISMS Forum Spain. Cómo podemos leer en su carta de presentación:
Creado en julio de 2009 con el objetivo de unir a todas las personas y organizaciones que tienen interés y responsabilidades en la privacidad y la protección de datos personales, promoviendo la formación y excelencia de sus asociados y facilitándoles cauces de interlocución con las administraciones y autoridades de control. El DPI pretende asimismo ser una vía para la difusión de mejores prácticas en el uso y la protección de los datos personales entre las empresas y particulares españoles.
- Asociación Profesional Española de Privacidad (APEP). Cómo podemos ver en su página web:
Constituida en junio de 2009 para integrar a profesionales de la protección de datos personales y de la privacidad para elaborar códigos éticos y certificaciones de competencias, fomentar el conocimiento y defender los intereses profesionales de sus asociados, velando por el interés general de la profesión de expertos en privacidad, y en especial, para el reconocimiento público de la misma.
Ambas organizaciones nacieron al únisono, así como sus correspondientes certificaciones:
- El DPI ha puesto a disposición de los profesionales la certificación denominada Certified Data Privacy Professional (CDPP).
- Por su parte, la APEP ofrece la APEP Certified Privacy (ACP) con la posibilidad de dos especializaciones:
- Auditor (A)
- Consultant & Security Manager (CSM)
Para aclarar un poco ambas certificaciones vamos a intentar hacer una tabla resumen de las características más destacadas de ambas:
Respecto al Grandfathering recordaremos que se trata del proceso de conseguir la certificación tras demostrar una cierta experiencia profesional en el ámbito de la Privacidad y la Protección de Datos.
Para poder tramitar el Grandfathering con el DPI será necesario cumplir con los siguientes requisitos:
- Estar en posesión de un título universitario oficial de Licenciado, Ingeniero o Diplomado
- Estar en posesión de un título de Master universitario o postgrado por más de 300 horas, en Derecho, Seguridad de la Información, Auditoría, o de Sistemas de Información
- Haber publicado al menos dos artículos en aspectos relacionados
- Haber realizado formación como formador en temáticas relacionadas
- Estos dos últimos requisitos pueden ser sustituidas acreditando alguna de las siguientes certificaciones en vigor: CIPP, CISA, CISM, CISPP o Lead Auditor ISO 2700.
Respecto a la APEP, estos son los requisitos para el proceso de apadrinamiento:
- Probar un mínimo de 40 proyectos relacionados con la PD, o
- Acreditar una experiencia mínima de 5 años en la materia
- Es posible convalidar 8 proyectos o 1 año (máximo de 16 proyectos o 2 años):
- Estar en posesión de un Máster en la materia
- Certificaciones: CISA, CISM, IAPP, etc
Para que este post no se alargue en demasía, en breve publicaremos otro para poder comparar los dos temarios que recientemente se han publicado en ambas organizaciones.
A partir de aquí, veremos que siglas son las que más proliferan dentro de unos meses…
Más información:
La Universitat Oberta de Catalunya y PRiSE firmaron el pasado 25 de febrero un convenio de colaboración para empezar a trabajar conjuntamente en proyectos de investigación e innovación muy interesantes para ambas instituciones.
Ya se ha publicado un borrador con la nueva versión del protocolo OAuth: OAuth 2.0.
Esta nueva versión se basa en lo que ya se definía en el protocolo, pero añadiendo nuevos perfiles y flujos de autorización, basados en OAuth WRAP, específicos para aplicaciones web, de escritorio, teléfonos móviles e incluso aplicables a dispositivos como los sistemas multimedia para el salón.
Los nuevos flujos y perfiles desarrollados se dividen en tres tipos:
- Flujos de Delegación de Usuario (User Delegation Flows):
Definen el protocolo de autorización para clientes que actúan en nombre de un usuario final. Hay distintos perfiles, dependiendo de la plataforma en la que se desarrollen: dispositivos externos, servidores web o programas de usuarios (navegadores web, etc.). - Flujos de Usuarios Finales (End-User Credentials Flows):
Se utiliza para clientes que actúan en nombre de los usuarios, pero permiten a la aplicación cliente tener acceso directo a las credenciales del usuario final, evitando el paso intermedio de pedir autorización al usuario directamente.
Estos tipos de flujos requieren una relación de confianza mayor entre el cliente y los usuarios. - Flujos autónomos (Autonomous Flows):
Flujos que permiten al cliente actuar en su propio nombre mediante sus propias credenciales o una aserción que será capaz de leer el servidor de autorización y comprobar si es válida o no.
Cuando facebook empezó a sonar dentro una pequeña comunidad, en aquellos entonces únicamente estaba en inglés, varios conocidos me enviaron una solicitud para que me apuntara a eso nuevo del facebook a mi cuenta de correo entonces@cuenta
La semana pasada recuperé la citada cuenta de correo y pensé en crearme una cuenta en facebook asociada a ésta.
Para mi sorpresa, ya tenía en mi perfil todo preparado para poder confirmar la relación de amistad con todas aquellas personas que habían solicitado ser mis “amigos” hace años. Por lo tanto:
1. Facebook tiene guardada toda dirección de correo a la que cualquier persona haya enviado una solicitud a través de Buscar a una persona
2. Facebook trata cuentas de correo de personas que no han solicitado el alta en la red social
Entro en Configuración de privacidad – Información de contacto e indico
que mi dirección de correo entonces@cuenta sólo la puedo ver yo.
Para mi confirmación, facebook me indica: Sólo yo puedo ver este contenido.
Verifico que en mi perfil no aparece la dirección de correo electrónico.
Después, realizo unas cuantas búsquedas. El facebook está para cotillear, no? 
Y igual que te buscas en Google, en facebook no vas a ser diferente. Término de búsqueda: entonces@cuenta. Recuerdo mi acción previa: indicar que la dirección de correo sólo sea visible para mi.
Y facebook encuentra un perfil que responde a esos términos de búsqueda, imagináis cual?
3. Facebook no respeta el nivel de privacidad indicado por el usuario
No todos tenemos el mismo concepto de “visibilidad” que facebook.
Ya está disponible la primera versión del conector PAPI para CAS. Éste es un sistema para autenticar usuarios en una institución desarrollado inicialmente por la Universidad de Yale y que posteriormente pasó a ser gestionado por la Jasig, un consortium de universidades norteamericanas.
Aunque CAS tiene su propio protocolo, ha sido diseñado de manera que pueda implementar otros protocolos, trayendo ya en la distribución oficial el interfaz de SAML 1.1, su única forma de emitir atributos, u OpenID.
Tras un acuerdo con la Valencian International University (VIU), PRiSE ha desarrollado un conector PAPI para CAS, con licencia GPL, para que un CAS pueda actuar como proveedor de identidad dentro de una infraestructura basada en PAPI.
La última versión está disponible en su página en la Forja y el código fuente está disponible en el repositorio de Mercurial http://www.prise.es/hg/papi-cas.