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.
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);
- Protegiendo el icGPoA, bien usando nuestro sistema favorito de Single Sign-On como simpleSAMLphp u Oracle Single Sign-On (OSSO), o bien utilizando módulos de Apache como mod_ldap o mod_auth (a través de un .htpassword). Sea cual sea el sistema, siempre obtenemos una referencia que identifica al usuario, como por ejemplo la cabecera REMOTE_USER en la petición HTTP. Gracias a esto podemos emitir los atributos en función de cada usuario.
- Incluyendo el típico formulario HTML, donde el usuario pondrá su nombre y contraseña y se le comprobará en la tecnología que hayamos decidido.
Aunque ya está siendo utilizado por más de 30 organizaciones, no existe una versión «oficial» que descargarse. Esperemos que en breve podamos anunciar una URL en este blog.
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.