Proxy para bibliotecas: como funciona o acesso remoto a bases de dados assinadas

O problema real: bases de dados que autenticam por endereço IP

Há décadas, a forma mais simples que os grandes fornecedores de bases de dados acadêmicas — pense em tipos de fornecedor como EBSCO, Scopus, JSTOR ou ProQuest — usam para controlar quem entra no seu conteúdo é verificar o endereço IP de onde chega a solicitação. Se esse IP está na faixa que a universidade registrou como “rede do campus”, o acesso é liberado sem mais perguntas. É um mecanismo cômodo enquanto o usuário está fisicamente no campus e completamente inútil quando ele se conecta de casa, de um café ou de outro país durante um intercâmbio: o IP já não é o do campus, e o fornecedor o trata como um desconhecido qualquer.

O Brasil tem um exemplo conhecido desse modelo. No Portal de Periódicos da CAPES, o conteúdo assinado é liberado nos terminais das instituições participantes a partir do registro dos IPs de cada instituição junto à CAPES, sem necessidade de senha. Fora dessa rede, o acesso remoto depende de um serviço oferecido pela própria instituição — e é exatamente aí que entram as duas soluções a seguir.

O modelo clássico de proxy para bibliotecas: proxy reverso que mascara o IP

O modelo mais difundido, popularizado por ferramentas como o EZproxy, funciona como proxy reverso com reescrita de URL. A biblioteca mantém uma lista de configuração com os endereços de cada base assinada. Quando um usuário fora do campus se autentica no proxy — normalmente com usuário e senha institucionais —, o sistema reescreve cada link para essas bases de modo que ele passe pelo próprio servidor proxy. Do ponto de vista do fornecedor, a solicitação chega de um IP que está na lista autorizada — o do proxy, não o do usuário —, e o acesso é concedido. O fornecedor nunca sabe quem é a pessoa do outro lado: só vê um IP que reconhece como da universidade.

Antes de deixar o usuário passar, esse mecanismo pode autenticá-lo de várias formas: contra uma base de usuários própria do proxy, contra um diretório institucional ou diretamente contra o sistema de gestão da biblioteca, por meio de protocolos padrão do setor como o SIP2, que consulta o número de usuário e a senha na mesma base de leitores usada pelo empréstimo (o Koha, por exemplo, expõe SIP2). É uma forma de reaproveitar uma identidade que a biblioteca já administra, sem duplicar usuários em um terceiro sistema.

O modelo alternativo: identidade federada com SSO

A alternativa, cada vez mais adotada por grandes bibliotecas universitárias, é a autenticação federada por protocolos como o SAML, com soluções como Shibboleth ou OpenAthens. Aqui não há mascaramento de IP: o usuário entra com a sua conta institucional — a mesma do e-mail ou do ambiente virtual — e a universidade certifica ao fornecedor da base, por um padrão de identidade federada, que aquela pessoa é de fato membro da instituição e tem direito de acesso. O fornecedor não vê um IP “de confiança”: vê uma asserção de identidade assinada pela universidade.

No Brasil, a referência é a CAFe (Comunidade Acadêmica Federada), a federação de identidade mantida pela RNP e baseada em Shibboleth e SAML. É por ela que funciona o Acesso CAFe do Portal de Periódicos da CAPES: usuários das instituições participantes da federação entram com login e senha institucionais e acessam remotamente o conteúdo assinado disponível para a sua instituição. Fora do Brasil, a Harvard Library é um exemplo documentado: migrou a sua autenticação do EZproxy para o OpenAthens e desativou o proxy legado em maio de 2026.

A diferença não é só técnica. O modelo de IP mascarado é mais simples de implantar e não exige que cada fornecedor configure uma integração de identidade, mas depende de manter listas de endereços e de o usuário lembrar de entrar pela porta certa. O modelo federado é mais robusto, porém exige uma coordenação de identidade mais exigente entre a universidade e cada fornecedor.

Na prática, muitas instituições não escolhem um modelo puro: mantêm os dois em paralelo por anos, com o proxy resolvendo as bases que ainda não suportam SAML e a identidade federada resolvendo as que já suportam. Não é defeito de projeto; é o estado real do setor, porque os fornecedores não migram todos ao mesmo tempo. O próprio Portal de Periódicos da CAPES reflete isso: cada instituição define o serviço de acesso remoto que oferece — CAFe, VPN ou proxy.

Por que o acesso remoto não deveria ser um serviço à parte

Este é o erro de orçamento mais frequente que vemos em bibliotecas que estão montando o seu projeto: tratar o proxy como uma licença independente, a ser orçada, instalada e mantida separadamente do metabuscador, quando o usuário só quer uma coisa — buscar e, se o resultado exigir uma base paga, entrar sem atrito, mesmo de casa. O BiblioMeta Académico integra o acesso remoto (proxy) como parte do mesmo serviço, e não como um contrato adicional: o usuário busca no metabuscador, encontra o resultado em uma base assinada e o sistema resolve o acesso remoto no mesmo fluxo, sem que ele precise configurar nada à parte nem lembrar de uma URL diferente para o “modo casa”.

Quando a BiblioLabTech implanta isso para uma universidade, a primeira pergunta não é qual software de proxy usar, e sim contra o que o usuário será autenticado: se a instituição já tem um diretório institucional com SSO, a conexão é feita ali; se o que ela tem é o sistema de gestão da biblioteca com a sua base de leitores, a conexão segue esse caminho. Evitamos deliberadamente forçar a universidade a montar uma identidade federada nova só para ter acesso remoto, quando o sistema atual já resolve o problema com menos peças em jogo.

O que a biblioteca precisa ter claro antes de pedir orçamento

Três pontos convêm estar claros antes de uma proposta. Primeiro, o inventário real das bases assinadas e da forma de autenticação que cada fornecedor aceita: alguns só aceitam IP, outros já aceitam SAML, muitos aceitam os dois. Segundo, contra qual base de usuários a identidade será validada: o sistema de gestão da biblioteca, um diretório institucional ou ambos. Terceiro, quem administra hoje essa base de usuários e com que frequência ela é atualizada, porque um proxy que valida contra um cadastro desatualizado deixa de fora usuários legítimos — a causa mais comum de chamados de suporte nesse tipo de projeto. A BiblioLabTech levanta esse inventário na fase de diagnóstico, antes de orçar, para não prometer uma integração de um dia com um fornecedor que, na verdade, exige semanas de coordenação.

Como viaja a credencial — e outros detalhes de privacidade

Quando a autenticação é feita contra o sistema de gestão da biblioteca, a conversa entre o proxy e o sistema — a troca do número de usuário e da senha — precisa trafegar criptografada, e não em texto puro pela rede interna. É um detalhe de infraestrutura que raramente aparece em uma proposta comercial e que aparece, tarde, em um relatório de auditoria. Nos projetos da BiblioLabTech, essa criptografia é verificada no checklist de entrada em produção, junto com a política de expiração de sessões e com quais dados do usuário chegam de fato ao fornecedor da base. A privacidade do leitor não é um detalhe menor em uma biblioteca acadêmica — no Brasil, ainda mais à luz da LGPD.

O que o BiblioMeta Académico é — e o que não é

Vale dizer com a mesma precisão que pedimos a qualquer fornecedor: o BiblioMeta Académico não é o EZproxy nem pretende ser, e também não é um serviço genérico de identidade federada como Shibboleth ou OpenAthens. É uma camada de acesso remoto integrada ao metabuscador, pensada para o caso de uso real de uma biblioteca universitária de porte médio — autenticar contra o que a instituição já tem, sem somar mais um sistema —, e não um substituto universal da arquitetura de identidade que uma grande universidade já tenha implantada. Se a sua universidade já opera uma federação SAML consolidada com dezenas de fornecedores, a conversa é diferente da de uma biblioteca que está começando a resolver o acesso remoto, e é assim que a abordamos em cada projeto.

No orçamento, o acesso remoto não é cotado como serviço separado: está integrado ao BiblioMeta Académico, cujos projetos, como referência publicada pela BiblioLabTech, costumam ficar entre US$ 4.000 e US$ 9.000 de implantação inicial. O que move o valor dentro dessa faixa é quantos fornecedores de bases é preciso coordenar e contra qual sistema os usuários serão autenticados.

Se você ainda não tem claro o que é um metabuscador e como ele se conecta a essas bases, comece pelo guia de metabuscador para bibliotecas; para ver o que a mesma plataforma faz com os documentos recuperados, leia sobre o assistente de pesquisa com IA. O acesso remoto integrado é implantado pelo nosso serviço de BiblioMeta Académico — fale com a BiblioLabTech para começar pelo inventário das suas bases.