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.