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.

Parece que OpenID está ganando poco a poco la confianza de las administraciones públicas en otros países a la hora de utilizarlo para autenticar a sus ciudadanos.

Como la mayoría sabréis, el pasado Septiembre’09 el gobierno americano anunció que comenzaría a incluir dicha tecnología en alguna de sus agencias gubernamentales y es ahora el gobierno japonés quien anuncia que va a permitir la autenticación de los usuarios en un portal del Ministerio de Economía, Comercio e Industria.

El portal, que se llama IdeaBox, es una iniciativa para conocer la opinión del ciudadano japonés con respecto a las iniciativas de dicho ministerio y que además, pueden proponer y votar, nuevas ideas. Aunque por ahora sólo van a confiar en 4 proveedores de identidad de OpenID:

• Yahoo! Japan
• Google
• Mixi
• LiveDoor

Enhorabuena al gobierno japonés por dicha iniciativa y estamos seguro que no tardaremos en ver en otros portales gubernamentales de otros países tecnologías como OpenID u OAuth.

Apache, como consecuencia de la vulnerabilidad CVE-2003-0020, escapa todos los logs de errores, con el fin de evitar que un atacante pueda insertar secuencias de caracteres de escape, y provocar vulnerabilidades en emuladores de terminal.
Pues bien esto hace que todos los caracteres de control sean impresos en los ficheros de log de errores con su representación visual (i. e. ‘\n’, \t’, etc), en vez de  actuar como tales. Por lo que depurar mensajes de error generados por cualquier componente externo a Apache, como por ejemplo aplicaciones PHP, scripts-cgi o handles mod_perl, es muy poco agradable, ya que te encuentras con mensajes de error de 10 o 15 líneas condensadas en una sola.

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.

El componente icGPoA de PAPI está experimentando un auge de popularidad en los últimos meses gracias a la labor de RedIRIS en su federación de identidad digital SIR.

Pero, ¿qué es un icGPoA?. Éste es un componente sencillo, extremadamente sencillo (y en cuanto se complique dejará de tener éxito), que permite actuar como GPoA o AS.

Así, el icGPoA sólo es capaz de responder a los siguientes mensajes:

• Mensaje ATTREQ de GPoA a AS: este tipo de mensaje solicita una lista de atributos del usuario.
• Mensaje CHECK de PoA a GPoA: donde el PoA solicita al icGPoA información de autenticación y atributos.

Para generar estas respuestas, el icGPoA sólo necesita una lista de atributos del usuario y una clave privada para firmarla (sobre esto ya hablaremos otro día…). En PHP tiene la siguiente “complejidad”:

if (isset($_REQUEST["ACTION"])) {
$theRef = $_REQUEST["DATA"];
}
else {
$theRef = $_REQUEST["PAPIPOAREF"];
}
$assertion = “attrA=val1,attrB=val2|val3@ID_AS”;
$now = time();
$ext = $now + 3600;
$reply = $assertion . “:” . $ext . “:” . $now . “:” . $theRef;
$safe = openssl_encrypt($reply, $pKey);

Hemos añadido una nueva sección a la web de PRiSE: Casos de éxito. En esta sección iremos mostrando algunos de los proyectos en los que hemos participado y que, bien por el alcance del mismo o bien por su solución técnica, nos gustaría comentar.

El primer caso del que hablamos es la solución desplegada a la empresa norteamericana de McGohan Brabender, que gestiona wellvibe.com, un portal médico de detección y seguimiento orientado a trabajadores, el cual necesita utilizar el servicio de formulario de evaluación de riesgos para la salud, de Wellsource. La solución por la que optamos fue desplegar un simpleSAMLphp y hacer la interconexión utilizando SAML 2.

Un perfil en OAuth especifica las credenciales que deben enviarse al Servidor de Autenticación y cómo las obtendrá el Cliente.

Dentro de los perfiles ya establecidos existen dos tipos: Perfiles de Clientes Autónomos (Autonomous Client Profiles), donde el Cliente actúa en su nombre y Perfiles de Delegación del Usuario (User Delegation Profiles), donde el Cliente actúa en nombre de un usuario determinado.

Los perfiles de Clientes Autónomos son dos:

Perfil de cuenta de Cliente con contraseña (Client Account and Password Profile):

Este perfil se utiliza cuando el Cliente es una aplicación que necesita un Recurso Protegido en nombre de una organización y el Servidor de Autorización acepta cuentas y contraseñas como método de autenticación.

Perfil de Aserción: (Assertion Profile)

Este perfil autoriza al cliente con una aserción, ya sea SAML u otro tipo que reconozca el Servidor de Autorización. El cliente presenta esta aserción al Servidor de Autorización y se intercambiarán por el Token de Acceso que permitirá acceder al recurso protegido.

Existen tres tipos de perfiles de Delegación del Usuario:

Perfil denombre de usuario y contraseña (Username and Password Profile):

El usuario da su nombre de usuario y contraseña a la aplicación Cliente que tiene instalada en su dispositivo. Con estos datos, el Cliente presenta sus credenciales al Servidor de Autorización para así intercambiarlas por un Token de Acceso que le permita acceder al recurso protegido.

Perfil Aplicación Web (Web App Profile)

Consiste en que el usuario se autentique de alguna forma determinada establecida de antemano en la aplicación web Cliente. Este perfil se utiliza cuando el Cliente es una aplicación web que accede al Recurso Protegido en nombre del usuario sin necesidad de adquirir las credenciales de los mismos.

Rich App Profile:

Se utiliza cuando el Cliente es una aplicación que el Usuario ha instalado en un dispositivo y está disponible en él un navegador web, pero el usuario no desea dar su nombre de usuario y contraseña a una aplicación o no necesita estos parámetros para autenticarse en el Servidor de Autorización.

Anoche, un poco antes de las 20h, empecé un pequeño proceso de investigación sobre el servicio Cercador d’expertes (buscador de expertas). Un directorio del Institut Català de les Dones (ICD, Instituto Catalán de las Mujeres) para que los medios de comunicación se puedan poner en contacto con mujeres expertas en una determinada materia.

Mi primera búsqueda fue en la APDCAT. Al tratarse de un organismo público de Catalunya, las competencias de los ficheros de protección de datos son de la agencia autonómica.
Diferentes búsquedas con diferentes valores en los diversos campos no dan ningún resultado exitoso. Así que envié un correo al ICD a través de su formulario de contacto. Recuerda, todo esto fuera de su horario laboral.

Pues bien, esta mañana a las 9.15, recibo una llamada del ICD para aclararme la situación y darme todos los datos necesarios para saber de la creación del necesario fichero.
Resumiendo: http://www.gencat.cat/diari/5256/08284057.htm

Impresionante. Yo aún sin tomarme el café y en el ICD ya había funcionado correctamente los procedimientos necesarios para que un usuario tuviera respuesta sobre una consulta en Protección de Datos.

Y es que un personal bien formado en la materia que tratamos hace que los procedimientos funcionen: que un correo, una consulta a través de un formulario, sea recibido o traspasado a la persona que debe realizar una determinada acción o a la que tenga el conocimiento necesario para resolver la consulta, depende del buen funcionamiento de la organización.

Es muy fácil que la organización tenga un buen documento de seguridad, unos procedimientos perfectamente redactados. Pero no es tan fácil que toda esa documentación llegue a todo el personal.

Lo triste de todo, que me sorprenda justamente que funcione bien. ¿No debería ser lo más normal?. Y un gustazo, una llamada para que no quede dudas de ningún concepto

Haciendo hincapié a mi búsqueda en la APDCat, he vuelto a buscar según los campos: DOGC 5256, obteniendo un resultado de 1021 resultados… Y teniendo en cuenta que una búsqueda más específica tampoco resultó, he realizado una consulta directamente a la APDCat para conocer como se debe realizar la esperada búsqueda.

Como comentábamos en otros posts, OAuth nos ofrece numerosas posibilidades a la hora de implementar la autorización y autenticación en nuestras aplicaciones.

En esta entrada vamos a comentar una extensión que está siendo definida actualmente y que amplía nuestra perspectiva a la hora de utilizar este protocolo.

Hablamos de OAuth WRAP (OAuth Web Resource Authorization Profiles), la cual nació para intentar simplificar a OAuth, eliminando sus procesos de firma y reemplazándolas por tokens de corta duración sobre SSL/TLS.

WRAP no pretende sustituir a OAuth, pero sí añadir nuevas características que completen y desarrollen elementos de los cuales carece el protocolo en su versión original.

Esta extensión permite la delegación de la autorización de recursos protegidos a una o más autoridades de confianza. Los Clientes que desean acceder a un Recurso Protegido primero obtienen autorización de un Servidor de Autorización, enviando para ello unas credenciales y perfiles determinados.

Una vez autorizados, el Cliente obtiene un Token de Acceso (Access Token) firmado digitalmente que podrá ser reemitido en caso de ser necesario y que permitira, como su nombre indica, acceder a los recursos protegidos.

OAuth WRAP define distintos perfiles que especifican las credenciales que deben enviarse al Servidor de Autenticación y cómo las obtendrá el Cliente. Es posible especificar perfiles propios e incluso adoptar los que ya están establecidos. En posteriores posts os comentaremos algunos de ellos.

En el laboratorio de I+D de PRiSE hemos estado trabajando en un sencillo test de rendimiento de directorios virtuales, como primer paso para evaluar si éstos son una opción viable en nuestras infraestructuras tecnológicas.

Un directorio virtual nos ofrece un interfaz LDAP que actúa de intermediario con respecto a otro sistema de información, como una base de datos o otro LDAP. Además, antes de servir al cliente los datos tiene la capacidad de trabajar con ellos por lo que pueden ser adecuados previamente a nuestras necesidades.

El directorio virtual que hemos desarrollado está basado en Perl y utiliza los paquetes Net::LDAP::Server y DBI. El objetivo es ver si al conectar dicho directorio virtual con una base de datos MySQL los tiempos son aceptables o no. Para ello, hemos creado una batería de tests donde se realiza la búsqueda N veces de manera secuencial de una entrada en el directorio. No se trataba de ver el rendimiento ante pruebas de stress sino ver si al menos superaba esta sencilla prueba.

Se ha realizado la siguiente batería de tests:

• 10 búsquedas
• 50 búsquedas
• 100 búsquedas
• 250 búsquedas
• 500 búsquedas
• 750 búsquedas
• 1000 búsquedas

Dicha batería se ha repetido 10 veces para quedarnos con el valor medio y evitar así resultados extraños. Los entornos que han sido probados y las búsquedas realizadas son:

• Búsquedas en un OpenLDAP.
  • DN base: dc=test,dc=org
  • Scope: base
  • Filtro: (objectClass=*)
  • Atributo requerido: description
• Búsquedas en un MySQL.
  • Sentencia SQL: select ‘dc=test,dc=org’ as dn, ‘dcObject\norganizationalUnit’ as objectClass, ‘test’ as dc, ‘test’ as ou, Test.Desc as description from Tabla where Id=’uno’
• Búsquedas en un directorio virtual que conecta con dicho MySQL.
  • DN base: dc=test,dc=org
  • Scope: base
  • Filtro: (Id=uno)
  • Atributo requerido: description

El directorio virtual realizará la búsqueda indicada para el MySQL a la hora de obtener los datos y responder al cliente LDAP.

Los resultados obtenidos son:

Como podemos ver, a medida que incrementamos el número de búsquedas secuenciales seguidas, el directorio virtual es el más lento de los 3, aunque dicho retraso es bastante aceptable, como veremos más adelante. También podemos ver que el acceso a BD termina siendo más rápido que a un LDAP, y es debido al sistema de caché de MySQL.

Pero veamos los valores, expresados en segundos, que obtuvimos:

Como podemos ver, al principio (con 10 búsquedas seguidas) el acceso a LDAP es más rápido que el acceso a la BD, ya que todavía el caché de la BD no ha comenzado a funcionar a pleno rendimiento. Además, el directorio virtual se comporta al mismo nivel que la base de datos. A medida que crece el número de peticiones, hay un retraso de un 35% aproximadamente, que gracias a que el tiempo de obtención de los resultados es bajo no va a implicar un coste elevado al integrar nuestras aplicaciones con el directorio virtual.

Tenemos claro que estas pruebas no son definitivas a la hora de evaluar un directorio virtual, pero al menos sabemos que si son cifras que prometen como para seguir trabajando en otro tipo de evaluaciones.

En la comunidad de desarrolladores de PAPI estamos trabajando en la definición del protocolo PAPI v1.1, que traerá algunas mejoras sobre la versión inicial, que ya iremos desvelando poco a poco en este blog.

Una de estas mejoras es la inclusión del parámetro opcional PAPIOPOA en un mensaje ATTREQ, el cual corresponde a una petición de atributos por parte de un PoA o GPoA. Cuando un proveedor de identidad PAPI recibe este tipo de mensaje, en el caso de que el usuario no se hubiese autenticado previamente, necesitará realizar la autenticación del usuario antes de generar la respuesta al GPoA/PoA.

De esta forma, el mensaje ATTREQ queda definido con la siguiente URL:

Mensaje ATTREQ

Donde,

• ATTREQ: contiene el ID del GPoA/PoA que ha realizado la petición.
• PAPIPOAREF: es un valor que establece el emisor del mensaje y que le será devuelto en la respuesta.
• PAPIPOAURL: es la URL del emisor que ha generado la redirección al proveedor de identidad.
• PAPIOPOA: en el caso de que el emisor del mensaje sea un GPoA y haya enviado el mensaje tras recibir solicitud de credenciales por parte de un PoA, este parámetro opcional incluirá la URL de dicho PoA que generó el mensaje al GPoA.

La principal utilidad de PAPIOPOA es facilitar la política de emisión de atributos de los proveedores de identidad. Consideremos el siguiente escenario:

Escenario PAPIOPOA

Como vemos, cada vez que el AS recibe un mensaje ATTREQ emitido por el GPoA, tendrá que emitir todos los atributos que podrían requerir cualquiera de los PoAs que están conectados con dicho GPoA.

Sin embargo, si en el mensaje ATTREQ recibe el parámetro PAPIOPOA, podremos saber cual fue el PoA que hizo la petición al GPoA y emitir sólo los atributos que dicho PoA necesita.

Además, este nuevo parámetro facilita enormemente la generación de unas estadísticas de acceso, ya que sabremos a qué recurso protegido intenta acceder un determinado usuario.