Resumen

  • RFC 9865 añade a SCIM un cursor opaco para pedir la página siguiente de la misma consulta, con el mismo endpoint y los mismos parámetros.
  • La especificación obliga a seguir aplicando la autorización de la identidad presente: tener el cursor no añade privilegios sobre ningún recurso.

Un proceso de alta o baja de identidades suele fallar en una transición pequeña: la primera página se obtiene con una cuenta autorizada, se guarda el nextCursor, cambian las pertenencias de grupo y más tarde un trabajo automático continúa como si el primer permiso hubiera quedado sellado dentro del valor. La comodidad es real; la conclusión no. RFC 9865 separa la continuidad de la consulta de la continuidad del derecho.

La primera petición usa cursor vacío o lo omite. Para avanzar, el cliente conserva el mismo endpoint del proveedor y todos los parámetros y valores originales; sólo sustituye el cursor por un nextCursor o previousCursor que recibió. El valor es opaco para el cliente. Salvo en la última página, una respuesta paginada debe llevar nextCursor; previousCursor es opcional y no cabe en la primera página. La regla preserva la identidad de la consulta. No preserva, por sí sola, la autoridad del actor ni el estado del conjunto de recursos.

Tampoco debe leerse el tamaño de la respuesta como una promesa de completitud. count fija un máximo deseado: el proveedor no puede devolver más, aunque sí puede devolver menos. El valor cero pide sólo totalResults, y este total puede omitirse si el proveedor no puede estimarlo. Que una página tenga cien identidades no demuestra que sean las únicas cien, que sigan siendo las mismas en el siguiente minuto ni que el cliente deba actuar sobre ellas sin otra comprobación. RFC 9865 admite que el cursor sea el único método de paginación y deja que el proveedor anuncie, si quiere, su modalidad predeterminada y sus capacidades.

El texto normativo cierra explícitamente la puerta más peligrosa: los resultados paginados deben limitarse a los datos que la identidad actual del actor está autorizada a consultar, incluso si el cursor proviene de un resultado generado para otra persona. Las verificaciones de autorización deben mantenerse durante todo el recorrido. La posesión del cursor no debe interpretarse como un privilegio adicional. Un diseño que cumple esta regla entiende el cursor como estado de navegación, no como una delegación abreviada.

Los cambios de permiso son la prueba de fuego. Cuando sea posible, el proveedor debería invalidar de inmediato los cursores asociados al actor que perdió o ganó permisos. Si no los invalida, debe actualizar los metadatos vinculados al conjunto de resultados para reflejar el nuevo alcance. Además, debe poder detectar cursores falsificados y evitar mensajes de error que permitan averiguar si un recurso existe pero queda fuera de alcance. Un cursor expirado no demuestra una revocación; una respuesta válida tampoco demuestra que el permiso original continúe. Cada observación tiene un alcance menor.

La disponibilidad añade otra razón para no convertir el cursor en un activo de gran alcance. Retener datos por cursor puede agotar el proveedor si se generan muchas consultas iniciales. RFC 9865 recomienda autenticar los conjuntos grandes, limitar ritmo, establecer techos administrativos y hacer eficiente la invalidación. La ausencia de valores publicados de duración, tamaño por defecto o máximo no significa que no haya límites locales. El contrato común no sustituye la configuración real.

La lectura de Heng Lu ayuda a conservar el orden de las pruebas. La RFC es una capa compartida que hace comprobable una forma de retomar una consulta. La decisión local sigue estando en la evaluación de identidad, en la política vigente, en la implementación y en el uso posterior de los datos. El cursor puede mover la conversación hacia adelante. El derecho tiene que volver a ganarse en cada respuesta.

Sources