Blog

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 Wellvibe, 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.