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.
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.
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.