Blog

EasyPoA es un PoA PAPI ligero desarrollado en PHP. Cuyo principal objetivo es facilitar la tarea de proteger aplicaciones web PHP por medio de protocolo PAPI.

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

Todos los compontes de PAPI desarrollados en PHP necesitan utilizar la función ‘openssl_pkey_get_details‘, ya que siempre se necesita trabajar con la clave pública RSA de algún componente de la infraestructura PAPI donde está desplegado.

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
)
);

Desde PRiSE queremos anunciar la salida a la luz de la página oficial de adAS (advanced Authentication Server).

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

En uno de nuestros proyectos nos hemos encontrado con la situación de tener que unir dos federaciones PAPI, permitiendo que personas que pertenezcan a una federación puedan acceder a los recursos federados de otra federación.

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.