Hay un par iniciativas en el IETF que van tomando forma y cuya filosofía está muy cerca de lo que PAPI proponía y propone. Si alguien tiene curiosidad, una vuelta a las especificaciones de JOSE y HOBA. Incluso OAuth, un mecanismo de acceso más que consolidado, tiene mucho en común con el intercambio de tokens en PAPI.

Ser pionero e ir (un poco) contracorriente tiene sus problemas, pero a la larga da cierto placer sentirse reivindicado…

La actual federación cuenta tanto con IdP’s y SP’s conectados a través de multiprotocolos (PAPI, SAML, OpenID, etc) y en su línea de vida está pendiente una reestructuración, por lo que muchas entidades se verán afectadas.

Uno de los principales cambios afectará a la actual integración multiprotocolo, eliminándola y permitiendo únicamente «usar SAML2 como protocolo intrafederación».

Si tu institución será una de las afectadas por no contar con un IdP que permita una integración con SAML te recomendamos que te pongas en contacto con nosotros para un cambio totalmente transparente para tus usuarios. Contamos con experiencia en IdP’s SAML, recomendándote el más adecuado para tu organización.

De la misma forma, contamos con múltiples servicios para tus aplicaciones PAPI, ayudándote a actualizarlas hacia otros protocolos, mejorarlas y/o gestionarlas.

Adelántate al futuro y asegúrate un cambio sencillo, fácil y transparente.

La primera release candidate de EasyPoA está disponible en papisoftware

Para conseguir que EasyPoA sea un componente ligero, se han restringido determinadas características comunes de los PoAs siendo la primera el hecho de no implementar el mensaje ATTREQ del protocolo PAPI, por lo que EasyPoA sólo puede hablar con GPoAs, puesto que no tiene la capacidad de interrogar a un AuthServer acerca de los usuarios.
También se ha eliminado la capacidad de realizar filtros de acceso basados en los datos recibidos en la aserción. De forma que la responsabilidad de realizar el control de acceso recae en la aplicación protegida.

EasyPoA no hace uso de las tradicionales cookies Hcook y LcooK, usadas por los componentes pesados de PAPI para mantener el contexto de seguridad. Así como tampoco necesita ficheros DB o bases de datos donde mantener los datos relativos a las peticiones de los usuarios. Sino que mantiene el contexto de seguridad y los parámetros de la petición original en la sesión PHP de usuario. Consiguiendo así un componente PAPI fácil de configurar en entornos de alta disponibilidad y balanceo de carga, sólo es necesario que los balanceadores mantengan las sesiones HTTP.

Por último se ha reducido el juego de directivas de configuración necesarias para configurar un PoA, y se ha optado por un fichero de configuración .ini de PHP

Para obtener más información sobre como instalar, configurar y usar EasyPoA, pueden encontrarla en EasyPoA@PAPISoftware

El problema que muchos de nosotros nos hemos encontrado cuando hemos realizado instalaciones de PAPI, es que algunas distribuciones de Linux, como Red Hat, sólo incluyen la versión 5.1.6 dentro de sus ramas o versiones estables.

En adAS hemos intentado hacer la vida más fácil a la hora de instalarlo, por lo que estamos incorporando una solución «de emergencia» (o workaround) para aquellas situaciones en las que es imposible actualizar la versión de PHP. ¿Cómo? Utilizando el ejecutable de OpenSSL.

La función de PHP ‘openssl_pkey_get_details’ necesita un parámetro con un objeto que representa a la clave y devuelve un ‘array’ con la siguiente estructura (para el caso de claves RSA, que es el que nos interesa):

array(

'bits' => ...,

'key' => ...,

'type' => 0,

'rsa' => array(

'n' => ...,

'e' => ...

),

)

Donde,

• bits: es el número de bits de la clave.
• key: es la clave en formato PEM.
• type: su valor es OPENSSL_KEYTYPE_RSA.
• rsa: es un array con la siguiente información
• • n: es el módulo de la clave RSA.
  • e: es el exponente de la clave RSA.

Toda esta información la podemos obtener también ejecutando el comando ‘openssl’, aunque lo obtendremos en otro formato:

$ openssl rsa -pubin -in test.pem -modulus -text

Modulus (1024 bit):

00:a8:cd:4f:02:e4:b3:2c:b7:3b:3b:77:7c:0f:c8:

9b:24:66:c9:92:9d:05:8e:4b:b4:50:14:8b:41:00:

19:f7:31:49:49:4a:38:40:81:8f:29:a4:99:eb:0c:

4c:ee:a3:6c:d5:04:a1:8a:1f:1b:33:2a:da:95:5e:

62:40:b1:2a:99:36:37:d5:1d:9a:99:26:b7:7b:11:

0c:37:84:e0:d0:15:42:1c:d3:b5:61:f7:0f:8a:b6:

ca:18:03:0d:36:c2:50:f5:ae:b5:60:16:c0:92:f3:

84:68:12:a8:e1:ce:72:21:c9:d1:2c:18:e4:e7:37:

c3:79:d8:22:38:86:2a:dc:97

Exponent: 65537 (0x10001)

Modulus=A8CD4F02E4B32C ... C18E4E737C379D82238862ADC97

writing RSA key

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCozU8C5LMstzs7d3wPyJskZsmS

nQWOS7RQFItBABn3MUlJSjhAgY8ppJnrDEzuo2zVBKGKHxszKtqVXmJAsSqZNjfV

HZqZJrd7EQw3hODQFUIc07Vh9w+KtsoYAw02wlD1rrVgFsCS84RoEqjhznIhydEs

GOTnN8N52CI4hirclwIDAQAB

-----END PUBLIC KEY-----

$data = explode("\n", trim($salida));

for ($i = 0; $i < count($data); $i++) {

$temp = explode(" ", $data[$i]);

if ($temp[0] == "Exponent:") {

$exp = $temp[1];

}

}

$e = base_convert($exp, 10, 16);

$e = asciihex2hex($e);

function asciihex2hex($str) {

while ((strlen($str) % 2) != 0) {

$str = "0" . $str;

}

$out = "";

for ($i = 0; $i < strlen($str); $i+=2) {

$out .= chr(hexdec($str[$i] . $str[$i + 1]));

}

return $out;

}

$data = explode("\n", trim($salida));

for ($i = 0; $i < count($data); $i++) {

$temp = explode(" ", $data[$i]);

if (strpos($data[$i], "Modulus=") !== false) {

$modulus = substr($data[$i], strlen("Modulus="));

}

}

$m = $modulus;

$m = self::asciihex2hex($m);

$res = array(
'bits' => $keylength,
'key' => $publickeypem,
'type' => 0,
'rsa' => array(
'n' => $m,
'e' => $e
)
);

Para los que aún no hayáis escuchado nada de él, adAS es un Servidor de Autenticación Avanzado que realiza funciones de proveedor de identidad y que integran los distintos protocolos que se engloban la identidad digital de una organización, como pueden ser PAPI v1, SAML 1.1/Shibboleth 1.3 o SAML 2.0.

adAS ofrece muchas ventajas con respecto a aplicaciones similares, pero una de las principales es la facilidad de gestión y mantenimiento de los sistemas integrados en este Single Sign-On, gracias a su interfaz web de administración. Mediante éste es posible configurar todos los aspectos que integran una aplicación de este tipo: gestión de proveedores de servicio, metadatos, políticas de atributos, soporte de diferentes fuentes de datos, etc.

Además, no solo se centra en facilitar la configuración y en tener un buen funcionamiento, si no que su objetivo es, además, facilitar el trabajo a los encargados de la identidad digital de las distintas organizaciones, integrando herramientas de visualización y búsquedas rápidas en los archivos de log, generando estadísticas de acceso y autenticación del sistema e incluso posibilitando el funcionamiento de esta herramienta con DNI electrónico.

¿Quiéres saber más sobre adAS?: Visita su nueva página web.

adAS Dashboard

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.

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

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.

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.

Como en mi día a día tengo que tratar con PAPI (desarrollado en mod_perl2) sufro bastante esta desconsideración de Apache al escribir los mensajes de debug que genera PAPI, vamos que tengo que manejar mensajes de debug de PAPI con el siguiente formato:

[Thu Mar 11 11:19:52 2010] [debug] ApachePoA.pm(105): [client 130.206.6.37]
 PAPI-DEBUG#20069_1268302792_sirgpoa: Parameters initialized:$VAR1 = bless( {\n
                    'Filtered' => 1,\n                 'Accept_File' =>
/aaaa/bbbb/cccc/dddd.ddddd/conf/papi/gpoa/shim.gif',\n                 
'String' => /GPoA',\n                 'attrList' => [],\n                 'filte
rs' => [],\n                 'PxCkSize' => 320768,\n                 ApacheReq
uest' => bless( do{\\(my $o = 11921096)}, 'Apache2::RequestRec' ),\n    'useHcoo
k' => 0,\n                 'Type' => 'Location',\n                 'Hcook_Ha
ndler' => undef,\n                 'registerKey' => '',\n                 'MxNonc
eErr' => 3,\n                 'PoARw' => [\n                              {\n              
                 'value' => 'check=false,$1,',\n

Lo que como se puede ver es inmanejable. Por esto un día decidí hacer uso de la capacidad que tiene el Apache para enviar los logs a un programa externo que recibirá estos logs por entrada estándar. Siendo en este programa externo donde reemplazo los caracteres de control (i.e. su representación visual) por su valor. Con lo que consigo log de debug de PAPI con el siguiente formato:

[Wed Mar 10 15:51:52 2010] [debug] ApachePoA.pm(105): [client 130.206.6.51]
PAPI-DEBUG#29900_1268232712_simplepoa: Parameters initialized:
$VAR1 = bless( {
                 'Filtered' => 1,
                 'Accept_File' => '/etc/apache2/papi/global/images/image_ok.png',
                 'String' => '/simplePoA',
                 'attrList' => [],
                 'filters' => [
                                {
                                  'reg' => '.*',
                                  'act' => 'accept'
                                }
                              ],
                 'PxCkSize' => 320768,
                 'ApacheRequest' => bless( do{\\(my $o = 155158008)},
                                              'Apache2::RequestRec' ),
                 'useHcook' => '1',
                 'Type' => 'Location',
                 'registerKey' => '',
                 'Hcook_Handler' => '.*',
                 'MxNonceErr' => 3,
                 'URL_Timeout' => '600',
                 'PoARw' => [],

Una mejora considerable ¿no?

El truco que hay que hacer consiste en definir el ErrorLog así:

ErrorLog "|/usr/local/bin/splitApacheLog.pl /path/papi_error.log /path/error.log"

Donde el progrma Perl splitApacheLog.pl consiste en:

 1 #!/usr/bin/perl
 2 
 3 my $papi = shift @ARGV;
 4 my $error = shift @ARGV;
 5 my $line = '';
 6 #$|=1;
 7 
 8 open(PAPI_OUT,">>$papi")
 9     or die("No se puede abrir el fichero $papi\n$!\n");
10 open(ERROR_OUT,">>$error")
11    or die("No se puede abrir el fichero $error\n$!\n");
12 
13 while (defined($line = )){
14     if ($line =~ /PAPI/){
15         $line =~ s/\\n/\n/g;
16         do { 
17             use bytes; 
18             my $size=length($line);
19             syswrite(PAPI_OUT, $line, $size);
20         }
21     }else{
22         $line =~ s/\\n/\n/g;
23         do {
24             use bytes;
25             my $size=length($line);
26             syswrite(ERROR_OUT, $line, $size);
27         }
28     }
29 }

Con esto conseguimos dos ficheros de log, uno para PAPI y otro para Apache, como se puede ver discriminamos con la expresión regular de la línea 14 según la cual enviamos la salida al fichero PAPI o al fichero de Apache.
El código es muy simple y intuitivo, por lo que modificarlo para que se ajuste a las necesidades de cualquiera no debe ser muy complicado.

Por último comentar, que se puede compilar Apache sin esta característica tan molesta de los mensajes de log escapados. Para ello sólo debéis hacer uso de la directiva de compilación DAP_UNSAFE_ERROR_LOG_UNESCAPED, tal y como os muestro a continuación:

CFLAGS=-DAP_UNSAFE_ERROR_LOG_UNESCAPED ./configure

Obviamente no recomiendo esta práctica, sólo informo de ella.