Archivado en la categoría (I+D+i, OAuth, PAPI) por diego.r.lopez
Publicado el 03-10-2014

Después de algunos años en los que ha venido demostrando su capacidad para desplegar infraestructuras de identidad digital a la vez flexibles, ligeras y seguras, al protocolo PAPI le han salido un par de primos de Zumosol que demuestran que las ideas que unos cuantos desarrollamos hace algún tiempo no eran tan malas, y que simplemente nacieron en un tiempo en el que XML y los esquemas complicados de Web Services era el credo dominante y cualquiera que fuera en contra de ellos era un hereje imperdonable.

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…

(0) Comments    Read More   
Archivado en la categoría (Identidad Digital, PAPI) por elena.galvan
Publicado el 11-08-2014

En los últimos grupos de trabajo de Rediris, a través de la ponencia Actualidad del servicio SIR, se dio a conocer el próximo futuro de la federación SIR.

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.

 

(0) Comments    Read More   
Archivado en la categoría (Identidad Digital, PAPI) por daniel.garcia
Publicado el 26-04-2011

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

(0) Comments    Read More   
Archivado en la categoría (Identidad Digital, PAPI) por candido.rodriguez
Publicado el 21-01-2011

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-----
Obtener el número de bits de la clave pública es bastante fácil ya que no tenemos que hacer ninguna conversión (de la clave pública en formato PEM ni hablamos, ya que sin ella no hubiésemos podido ejecutar dicho comando).
El exponente se nos indica en hexadecimal: 0x10001. Éste valor hemos de procesarlo en PHP de la siguiente manera:
$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);
Como vemos, nos quedamos con el valor en decimal que nos indica OpenSSL, 65537 en nuestro ejemplo, y lo pasamos a hexadecimal cambiando la base de 10 a 16. Como obtendremos el valor ‘10001’, utilizaremos la siguiente función para obtener el valor en decimal:
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;
}
Con respecto al módulo de la clave RSA, OpenSSL nos ofrece su valor en hexadecimal en una cadena de texto, por lo que para pasarlo a decimal número utilizaremos la siguiente receta:
$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);
De esta forma ya tenemos toda la información que nos hubiese dado la función de openssl ‘openssl_pkey_get_details':
$res = array(
'bits' => $keylength,
'key' => $publickeypem,
'type' => 0,
'rsa' => array(
'n' => $m,
'e' => $e
)
);
(0) Comments    Read More