Library proxy for remote access to databases: how it works and EZproxy alternatives

The real problem: databases that authenticate by IP address

For decades, the simplest way for large academic database providers (think of the kind of platforms EBSCO, Scopus, JSTOR or ProQuest run) to control who gets in has been to check the IP address a request comes from. If that IP falls within the range the university registered as its campus network, access is granted with no further questions. The mechanism is convenient while the user is physically on campus, and useless as soon as they connect from home, a café or another country during an exchange: their IP is no longer the campus IP, and the provider treats them as a stranger.

A remote access solution fixes exactly that mismatch, and it does so in two technically different ways that should not be confused.

How a library proxy for remote access works: the EZproxy model

The most widespread model, popularized by EZproxy, OCLC's access and authentication software, works as a reverse proxy with URL rewriting. The library keeps a configuration list with the address of each subscribed database. When an off-campus user authenticates with the proxy, the system rewrites every link to those databases so that traffic passes through the proxy server. From the provider's point of view, the request arrives from an IP address on its authorized list, the proxy's rather than the user's, so access is granted. The provider never learns who the individual on the other end is; it only sees an IP it recognizes as belonging to the university.

Before letting a user through, a proxy can authenticate them in several ways: against its own user list, against an institutional directory, or directly against the integrated library system using industry protocols such as SIP2, which checks the patron's card number and password in the same patron database that circulation uses. That reuses an identity the library already manages, without duplicating users in a third system.

Proxying and single sign-on are not mutually exclusive, either. OCLC's documentation of EZproxy authentication methods lists LDAP, SIP, CAS and SAML, including Shibboleth and OpenAthens, among the ways a user can sign in to the proxy, while the database provider still sees the proxy's IP address.

Federated identity: SAML single sign-on

The alternative, increasingly adopted by large university libraries, is federated authentication through the SAML standard, with solutions such as Shibboleth, open-source software maintained by the Shibboleth Consortium, or OpenAthens, a cloud identity and access management service from Jisc. There is no IP masking here. The user signs in with their institutional account (the same one used for email or the learning platform), and the university certifies to the database provider, through a federated identity standard, that this person is a member of the institution and entitled to access. The provider does not see a trusted IP; it sees an identity assertion signed by the university, and which attributes are shared with it depends on what the university configures with each provider.

The difference is not only technical. IP-based proxying is simpler to deploy and does not require each database provider to configure an identity integration, but it depends on maintaining address lists and on users entering through the right door. The federated model is more robust, and large institutions have been adopting it as a replacement for, or a complement to, the classic proxy. Harvard Library, for example, retired its EZproxy service on May 31, 2026 and now provides remote access through OpenAthens, according to its own announcement. The trade-off is heavier identity coordination between the university and each provider.

Library proxy vs federated sign-on, side by side

In practice, many institutions do not pick a pure model: they run both in parallel for years, with the proxy covering databases that do not yet support SAML and federated identity covering those that do. That is not a design flaw; it is the real state of the industry, because not every database provider migrates at the same time.

EZproxy alternatives: what the options really are

Libraries searching for EZproxy alternatives are usually choosing between architectures more than between brands. Stated neutrally, the options are:

1. An IP-based proxy, such as EZproxy, which OCLC offers as a fully managed hosted service. Users can sign in through the methods listed above; toward providers, access remains IP-based.
2. SAML federated access, through self-run open-source software such as Shibboleth or a managed service such as OpenAthens. It requires each provider to support SAML.
3. A hybrid of the two: a proxy for IP-only resources and SAML for the rest, which is the real-world state of many libraries.
4. Remote access built into the discovery layer, the approach of BiblioMeta Académico: the user searches, finds a result in a subscribed database and access is resolved in the same flow.

The right choice depends on three inventories: which authentication each provider accepts, which identity source the institution already runs, and who maintains it.

Why remote access belongs inside the metasearch engine

This is the most frequent budgeting mistake BiblioLabTech sees in libraries planning their projects: treating the proxy as an independent license to quote, install and maintain separately from the metasearch engine, when users really want one thing. They want to search and, if the result requires a paid database, get in without friction from home. BiblioMeta Académico integrates remote access (proxy) as part of the same service, not as an additional contract. The user searches in the library metasearch engine, finds the result in a subscribed database and the system resolves remote access in the same flow, without configuring anything separately or remembering a different URL for "home mode".

When we implement this for a university, the first question we settle is not which proxy software to use, but what the user will be authenticated against. If the institution already has an institutional directory with single sign-on, that is where we connect. If what it has is the integrated library system and its patron database, we connect that way, for example over SIP2 to Koha. We deliberately avoid forcing a university to stand up a new federated identity just to get remote access when its current system already solves the problem with fewer moving parts.

What to have ready before you ask for a quote

1. An inventory of subscribed databases and the authentication each provider accepts: some only accept IP, others already accept SAML, and many accept both.
2. The user base that identity will be validated against: the integrated library system, an institutional directory, or both.
3. Who maintains that user base today, and how often it is updated. A proxy that validates against an outdated patron list locks out legitimate users, and that is the most common cause of support tickets in this kind of project.

BiblioLabTech builds that inventory during the assessment phase, before quoting, so as not to promise a one-day integration with a provider that actually requires weeks of coordination.

The detail few people ask about: how credentials travel

When authentication runs against the integrated library system, the exchange between the proxy and the ILS (the patron's card number and password) must travel encrypted, not as plain text across the internal network. It is an infrastructure detail that rarely appears in a commercial proposal and that does appear, late, in an audit report. In our projects, that encryption is verified as part of the go-live checklist, together with the session-expiry policy and exactly which user data reaches the database provider, because patron privacy is not a minor detail in an academic library.

What BiblioMeta Académico is, and what it is not

It is worth saying with the precision we ask of any vendor: BiblioMeta Académico is not EZproxy and does not try to be, and it is not a generic federated identity service like Shibboleth or OpenAthens either. It is a remote access layer built into the metasearch engine, designed for the real use case of a mid-sized library: authenticate against what the institution already has, without adding one more system. It is not a universal replacement for whatever identity architecture a large university has already deployed. If your university already runs a consolidated SAML federation with dozens of providers, the project is about connecting BiblioMeta Académico to that federation rather than building identity from scratch, and that is how it is scoped and quoted.

What remote access costs with BiblioMeta Académico

Remote access is not quoted as a separate service: it is part of BiblioMeta Académico. As a reference range published by BiblioLabTech, a BiblioMeta Académico project with natural-language search, the AI research assistant and integrated remote access across several commercial databases typically costs between USD 4,000 and 9,000 to implement, with the upper end for institutions with many subscribed databases and several providers to coordinate. Within that range, the price moves with how many database providers need to be coordinated and which system users will authenticate against.

If your project is still taking shape, read what the AI research assistant adds on top of search, then tell us about your databases and we will scope remote access on your real inventory.