Problemática-eduPersonTargetedId

En este artículo describimos la problemática asociada a este atributo, para el cual el cálculo correcto de sus posibles valores puede influir en el uso actual de la federación SIR y en el uso futuro en SIR2.

1 Definición de este atributo

La definición de eduPersonTargetedID (se corresponde con urn:oid:1.3.6.1.4.1.5923.1.1.1.10 o, en clave PAPI, con ePTI) puede encontrarse dentro del schema eduPerson, el cual lo define como:

A single string value of no more than 256 characters that uniquely identifiers a user in an opaque, privacy-preserving fashion. In most cases, the value will be different for a given user for each service provider to which a value is sent, to prevent correlation of activity between service providers. [InCommon]

Es decir, una cadena de no más de 256 caracteres que identifique unívocamente a un usuario de manera opaca, de modo que preserve la privacidad del mismo. Además, esta cadena será usualmente diferente por cada Proveedor de Servicio (SP) al que enviemos dicho atributo, para evitar que puedan realizarse correlaciones entre distintos SP.

Dicho atributo se utiliza en algunos SP para identificar al usuario. Es decir, podemos verlo como una clave primaria para la cuenta local (en el SP) que representa al usuario autenticado. Es, por tanto, vital que el valor tenga persistencia, se mantenga inmutable a lo largo del tiempo y no se reutilicen sus valores. Los problemas que pueden originarse si el atributo no tiene estas cualidades son:

  • un usuario entra en el SP y tiene un perfil distinto al que ya había generado anteriormente (si el ePTI cambia de valor para un usuario)
  • un usuario entra en el SP y se encuentra con un perfil de otro usuario distinto (si el ePTI se reutiliza o no se genera a partir de un dato único y no reutilizable)
  • un usuario utiliza varios SP y esto permite trazar sus actividades (si el ePTI no es distinto para cada SP)

Hay que tener en cuenta que muchos SP consumen otros atributos del usuario (mail, displayName, etc.) que permiten "saltarse" la privacidad obtenida con un ePTI opaco y que facilitan el seguimiento de un usuario en su uso de diferentes SP.

2 Cálculo de eduPersonTargetedId

Una vez hemos visto las características que ha de tener el atributo, veamos cuál sería la mejor opción para generarlo:

  • partimos de un atributo del usuario que sea único, permanente y no reutilizable
    • el uid o netId serían buenas opciones
    • el mail podría ser válido si la institución garantiza que no se reutilizarán en ningún caso
    • no puede utilizarse el nombre, la afiliación y otros atributos no únicos
  • tenemos en cuenta la institución origen del usuario
    • para evitar que dos identificadores idénticos en dos instituciones distintas den lugar al mismo ePTI
  • utilizamos el identificador del SP al que quiere acceder el usuario
    • para que la actividad de un usuario en distintos SP no pueda relacionarse
  • generamos un hash salpimentado con los valores anteriores
    • para que el identificador sea opaco

Con todas estas premisas, podemos obtener un ePTI correcto con una fórmula del siguiente estilo:

eduPersonTargetedId= HASH(idUsuario + idDestino + idOrigen + sal)

3 Determinando el Proveedor de Servicio

En federaciones Hub&Spoke como SIR2, es el Hub el que habla con los IdP y hay que tener cuidado con la identificación del SP final.

Cuando llega una petición SAML a un IdP conectado a SIR2, se recibirán los siguientes datos:

<samlp:AuthnRequest ...>
    <saml:Issuer ...>https://sir2.rediris.es/hub/metadata/sml/saml2/</saml:Issuer>
    <samlp:Scoping>
        <samlp:RequesterID>https://sp.example.com/saml/</samlp:RequesterID>
    </samlp:Scoping>
</samlp:AuthnRequest>

El valor de RequesterID (en el atributo Scoping) hace referencia al SP al que quiere acceder el usuario. Es el que utilizaremos para el cálculo de eduPersonTargetedId.

El valor de Issuer (generalmente aceptado como destino en SAML) corresponde al hub de SIR2.

Podemos tener otro problema con la identificación del SP cuando éste utilice distintas URL como destino. Por ejemplo, un servicio de blogs podría utilizar una URL distinta para cada uno de los blogs albergados:

En realidad, el SP es único y deberíamos generar un único ePTI para todos los blogs. Así pues, puede ser necesaria una transformación de la URL obtenida para garantizar un ePTI único por SP (en OpenID Connect se maneja el concepto de Sector Identifier para esta problemática).

Permitir la manipulación de las URL también nos facilita la obtención de ePTI más apropiados en otros casos. Por ejemplo: la FECYT actúa como proxy de acceso a distintos SP. Si generamos un ePTI único para la FECYT, se podría relacionar la actividad del usuario en cada uno de los SP finales.

4 Uso del ePTI por parte de los SP

Algunos SP utilizan el valor del ePTI para identificar al usuario. De ahí la importancia de generar un ePTI único y persistente.

Esta funcionalidad hace que los cambios en la generación del atributo puedan ser problemáticos: si un usuario entra al SP con un ePTI distinto, será un usuario distinto para dicho SP.

Un usuario "normal" puede perder los datos almacenados en el SP si cambiamos su ePTI. Pero también los usuarios "administradores" tendrán problemas: no se les permitirá la gestión del SP.

Ejemplo: eBrary utiliza el ePTI para identificar a (todos) los usuarios. Ante un cambio en los valores generados para el ePTI:

  • los usuarios estándar perderán las búsquedas almacenadas, las anotaciones, los libros de su estantería, etc.
  • los técnicos de la Biblioteca que gestionan la suscripción a eBrary no podrán administrar el portal

Dado que el atributo eduPersonTargetedId puede contener múltiples valores, si el SP hace una gestión correcta del mismo, se podría pasar de un ePTI a uno distinto manteniendo durante un tiempo el valor antiguo y el nuevo valor.

5 Paso de atributos desde SIR2 a SIR1 durante la migración

Recordamos las conexiones entre sistemas durante la fase 3 de la migración:

Graficomigracionfase3.jpg


Mientras se produce la transición hacia SIR2, ambos hubs van a estar conectados, por lo que tenemos que poner especial cuidado en qué significa cada atributo en cada uno de los hubs, y según el IdP que la institución tenga conectado en un determinado momento. A continuación explicamos por tanto la situación del atributo en ambas federaciones y durante la transición.

6 eduPersonTargetedID en SIR1

En las distintas implementaciones del cálculo del valor del atributo en SIR1, no se ha tenido por lo general en cuenta que el identificador sea targeted, implicando esto que se ha reutilizado el mismo valor para todos los proveedores de servicio. Esto, no siendo especialmente grave, hay que tenerlo en cuenta.

Versiones muy antiguas del conector calculaban el valor de ePTI (el atributo en clave PAPI) usando el número del proceso Apache, calculado mediante una llamada a la función getmypid() de PHP. Esto está lógicamente mal, pues aparte de que se emiten identificadores iguales para distintos usuarios, estos no son persistentes. Este fallo fue comunicado por la lista de correo en su día y la mayoría de proveedores de identidad (IdP) –si no todos– deberían tener el fallo corregido.

Posteriormente se decidió unificar el cálculo de este identificador. En el paso 4 de la Guía de IdPs de SIR1 se dice:

Es importante notar que, dado que eduPersonTargetedID es un atributo orientado a preservar la privacidad del usuario y, por tanto, opaco, se ha usado en este ejemplo el hash MD5 del nombre "Antonio David Pérez Morales".

Siendo este el ejemplo, en muchos de los conectores distribuidos por RedIRIS el cálculo se realizaba con la llamada PHP:

    $assertion = "ePTI=".md5($username."SIR"). ....

Que evolucionó a la siguiente fórmula:

    $epti= sha1($netid);

Otras instituciones pueden haber elegido formulas similares a éstas, que deberán ser revisadas, sobre todo en función de los proveedores de servicio a los que acceden sus usuarios.

Este atributo ha dado en general pocos problemas y, cuando ocurrieron, estaban relacionados con un cambio de nombre (o incluso de codificación, al añadir acentos o realizar un cambio mínimo en éste).

7 eduPersonTargetedID en SIR2

En SIR2, y desde IdPs SAML2int, tenemos la posibilidad de calcular bien el valor del atributo si no se hacía así hasta ahora, pero tenemos el inconveniente de que si cambiamos los valores de dicho identificador en SPs que vinieran utilizándolo hasta ahora, la vinculación de cuentas anteriores podría perderse.

Miguel Macías, de la Universitat Politècnica de València ha desarrollado un módulo para SimpleSAMLphp que permite generar distintos valores para el atributo:

  • un valor "correcto", con todas las propiedades requeridas para el ePTI
  • un valor "antiguo", que entregue el mismo ePTI que se generaba en SIR1 (para ciertos SP y/o usuarios)

8 La transición desde SIR1 a SIR2

En SIR1 el valor que se utilizaba para realizar el cálculo de un atributo targeted, es el parámetro PAPIOPOA. En SIR2 el hub pasa al IdP el valor del entityId correspondiente al proveedor de servicio que envió la petición. Estos dos valores se buscará que coincidan en la migración. Es decir, al migrar un proveedor de servicio de SIR1 a SIR2, se mantendrá el mismo identificador, tanto para peticiones PAPI como SAML2int.

A medida que se vayan pasando los SP desde SIR1 a SIR2 se investigará si el SP utiliza el atributo eduPersonTargetedId y cómo lo utiliza (si es la clave del usuario, si permite trabajar con múltiples valores, etc.).

Para evitar complicaciones se puede empezar la migración enviando ambos valores del ePTI, para finalizar con un único valor calculado de manera correcta.

9 Comportamiento del nuevo hub: cacheo de atributos

En la versión inicial del hub de SIR2, se tratará de dar prioridad a la transparencia en el envío de atributos a SPs que estarán inicialmente conectados al hub de SIR1, es por ello que el tiempo de duración de las sesiones será corto (en el hub de SIR2), prevaleciendo la sesión que se establezca en el hub de SIR1.

Posteriormente, a medida que se incorporen SPs directamente al hub de SIR2, tendrá sentido tomar medidas como las siguientes que están en estudio:

  • control de sesiones por SP en el hub. La idea de esta medida es que el hub mantenga sesiones distintas por cada SP, de modo que no compartan valores de atributos, sobre todo de aquellos que sean susceptibles de ser distintos según el SP, tal es el caso de eduPersonTargetedID.
  • habilitar mecanismos para controlar la duración de una sesión en el hub por medio del valor de atributos enviados desde el IdP. Tiene cierto sentido que el propio IdP delimite la duración de sesiones en el hub, de modo que para determinados SPs, o incluso usuarios pertenecientes a un grupo, siempre se fuerce la autenticación.