Proxy para bibliotecas: acceso remoto

El problema real: bases de datos que autentican por dirección IP

Desde hace décadas, la forma más simple en que los grandes proveedores de bases de datos académicas —piensa en tipos de proveedores como EBSCO, Scopus, JSTOR o ProQuest— controlan quién puede entrar a su contenido es revisar la dirección IP desde la que llega la solicitud. Si esa IP está en el rango que la universidad registró como «red del campus», el acceso se concede sin más preguntas. Es un mecanismo cómodo mientras el usuario está físicamente en el campus, y completamente inútil apenas se conecta desde su casa, desde un café o desde otro país en un intercambio académico: su IP ya no es la del campus, y el proveedor lo trata como un desconocido más.

El proxy de acceso remoto resuelve exactamente ese desajuste, y lo hace de dos maneras técnicamente distintas que conviene no confundir.

El modelo clásico: proxy inverso que enmascara la IP

El modelo más extendido, popularizado por herramientas como EZproxy, funciona como proxy inverso con reescritura de URL. La biblioteca mantiene una lista de configuración con las direcciones de cada base de datos suscrita. Cuando un usuario fuera del campus se autentica frente al proxy —normalmente con su usuario y contraseña institucional—, el sistema reescribe cada enlace hacia esas bases de datos para que pase por el propio servidor proxy. Desde el punto de vista del proveedor de la base de datos, la solicitud llega desde una IP que sí está en su lista autorizada —la del proxy, no la del usuario—, así que la concede. El proveedor nunca sabe quién es la persona concreta que está del otro lado: solo ve una IP que reconoce como perteneciente a la universidad.

Este mecanismo puede autenticar al usuario de varias formas antes de dejarlo pasar: contra una base de usuarios propia del proxy, contra un directorio institucional, o directamente contra el sistema de gestión bibliotecaria mediante protocolos estándar de la industria como SIP2, que consulta el número de carné y la contraseña del usuario en la misma base de patrones que usa el préstamo. Es una forma de reutilizar una identidad que la biblioteca ya gestiona, sin duplicar usuarios en un tercer sistema.

El modelo alternativo: identidad federada con SSO

La alternativa, cada vez más adoptada por las bibliotecas universitarias grandes, es la autenticación federada mediante protocolos como SAML, con soluciones como Shibboleth u OpenAthens. Aquí no hay enmascaramiento de IP: el usuario inicia sesión con su cuenta institucional —la misma que usa para el correo o el campus virtual— y la universidad le certifica al proveedor de la base de datos, mediante un estándar de identidad federada, que esa persona es en efecto miembro de la institución y tiene derecho a acceder. El proveedor no ve una IP «de confianza»: ve una aserción de identidad firmada por la universidad.

La diferencia no es solo técnica. El modelo de IP enmascarada es más simple de desplegar y no exige que cada proveedor de base de datos configure una integración de identidad, pero depende de mantener listas de direcciones y de que el usuario recuerde entrar por la puerta correcta. El modelo federado es más robusto y es el que instituciones grandes —bibliotecas como la de Harvard, por citar una migración documentada en 2026— vienen adoptando como reemplazo o complemento del proxy clásico, aunque exige una coordinación de identidad más exigente entre la universidad y cada proveedor.

En la práctica, muchas instituciones no eligen un modelo puro: corren los dos en paralelo durante años, con el proxy resolviendo las bases de datos que aún no soportan SAML y la identidad federada resolviendo las que sí. No es un defecto de diseño, es simplemente el estado real de la industria, porque no todos los proveedores de bases de datos migran a la vez.

Por qué esto no es un servicio aparte, sino una función del metabuscador

Aquí está el error de presupuesto más frecuente que vemos en bibliotecas que están armando su proyecto: tratan el proxy como una licencia independiente que hay que cotizar, instalar y mantener por separado del metabuscador, cuando el usuario en realidad solo quiere una cosa: buscar y, si el resultado exige una base de datos pagada, entrar sin fricción aunque esté en su casa. BiblioMeta Académico integra el acceso remoto (proxy) como parte del mismo servicio, no como un contrato adicional: el usuario busca en el metabuscador, encuentra el resultado en una base de datos suscrita y el sistema resuelve el acceso remoto en el mismo flujo, sin que tenga que salir a configurar nada aparte ni recordar una URL distinta para «modo casa».

Cuando implementamos esto para una universidad, la primera pregunta que resolvemos no es qué software de proxy usar, sino contra qué se va a autenticar al usuario: si la institución ya tiene un directorio institucional con SSO, ahí se conecta; si lo que tiene es el sistema de gestión bibliotecaria con su base de patrones, se conecta por ese camino. En los proyectos que hacemos evitamos deliberadamente forzar a la universidad a montar una identidad federada nueva solo para tener acceso remoto, cuando su sistema actual ya resuelve el problema con menos piezas en juego.

Qué necesita la biblioteca antes de pedirlo

Tres cosas conviene tener claras antes de una cotización. Primero, el inventario real de bases de datos suscritas y su forma de autenticación aceptada por cada proveedor —algunos solo aceptan IP, otros ya aceptan SAML, y muchos aceptan ambas—. Segundo, contra qué base de usuarios se va a validar la identidad: el sistema de gestión bibliotecaria, un directorio institucional, o los dos. Tercero, quién administra hoy esa base de usuarios y con qué frecuencia se actualiza, porque un proxy que valida contra un padrón desactualizado deja afuera a usuarios legítimos y es la causa más común de tickets de soporte en este tipo de proyectos. Nosotros levantamos ese inventario en la fase de diagnóstico, antes de cotizar, para no prometer una integración de un día contra un proveedor que en realidad exige coordinación de varias semanas.

No inventamos lo que no está verificado

Un detalle que casi nadie pregunta y debería preguntar: cómo viaja la credencial

Cuando la autenticación se hace contra el sistema de gestión bibliotecaria, la conversación entre el proxy y el ILS —el intercambio del carné y la contraseña del usuario— debe viajar cifrada, no en texto plano por la red interna. Es un detalle de infraestructura que rara vez aparece en una propuesta comercial y que sí aparece, tarde, en un informe de auditoría. En los proyectos que hacemos verificamos ese cifrado como parte del checklist de puesta en marcha, junto con la política de expiración de sesiones y qué datos del usuario llegan realmente al proveedor de la base de datos, porque la privacidad del patrón no es un detalle menor en una biblioteca académica.

Vale la pena decirlo con la misma precisión que le pedimos a cualquier proveedor: BiblioMeta Académico no es EZproxy ni pretende serlo, y tampoco es un servicio de identidad federada genérico como Shibboleth u OpenAthens. Es una capa de acceso remoto integrada al metabuscador, pensada para resolver el caso de uso real de una biblioteca latinoamericana mediana —autenticar contra lo que la institución ya tiene, sin sumar un sistema más— y no un reemplazo universal de cualquier arquitectura de identidad que una universidad grande ya tenga desplegada. Si tu universidad ya opera una federación SAML consolidada con decenas de proveedores, la conversación es distinta a la de una biblioteca que recién empieza a resolver el acceso remoto, y así la abordamos en cada proyecto.

Si todavía no tienes claro qué es un metabuscador y cómo se conecta con estas bases de datos, empieza por qué es un metabuscador y cómo funciona. Si lo que necesitas es entender la parte de integración de fuentes en sí, revisa cómo integrar bases de datos suscritas en un solo buscador. Y si estás dimensionando el presupuesto completo, lee cuánto cuesta implementar un metabuscador, donde el acceso remoto aparece como uno de los factores que mueve el precio. Implementamos el acceso remoto integrado desde nuestro servicio de BiblioMeta Académico.