Admins: Remote access options

On-campus“, patrons can access your ebrary site without providing credentials if we’ve pre-validated your on-campus IP addresses (IP-authentication).

Off-campus“, patrons can access your ebrary site if you provide a remote access protocol requiring them to log in with a unique username/password or barcode.


1. Proxy server:

  • If your institution/company uses a proxy server to provide access to online shared resources, we can work with you to easily configure it for ebrary. This is a desirable solution if your patrons are already familiar with their proxy server login credentials.  Typical proxy servers are EZproxy, WAM, and Squid.
  • For EZproxy servers, you can choose a Single Sign On (SSO) option that sends users through the proxy server to sign in to their personal ebrary account as well.  This method provides faster remote access than basic proxy access, and patrons typically appreciate needing only one set of login credentials.  (EZproxy v4.0+ is required, v5.0+ is preferred.)

2. OpenAthens or Shibboleth:

  • These authentication methods work particularly well if your patrons are already familiar with their login credentials.
  • To sign in to a personal ebrary account, users will be sent to the institution’s Athens or Shibboleth login page and must sign in there.
  • Shibboleth authentication is offered through the following federations:
    • UK Federation –  SP WAYFless access (UK)
    • InCommon Federation (USA)
    • German Federation – SP WAYFless access (Germany)
    • EduGate Federation (Ireland)
    • RedIRIS Identity Service (SIR, Spain)
    • Federation (Czech Republic)
    • GakuNin (Japan)
    • Check with for Shibboleth authentication availability in other regions.
  • Shibboleth authentication requires the following 2 attributes to be passed:
    1. This attribute is required:
    2. And one of the three following attributes is required:

3. VPN, Virtual Private Network:

  • ebrary works well with VPNs as long as they are not URL-rewriting.
    URL-rewriting VPN is not supported.

4. Referring URL:

  • If your institution or company website already offers a secure login for your patrons, we might be able to pre-validate users accessing ebrary from behind the login page.
  • You would put a link to ebrary on one or more of your webpages that can only be accessed after having signed in through your website’s secure login.  You would then give us the URL of that webpage, and we would pre-validate all users coming from that URL.  Your off-campus patrons would need to access ebrary using the link on that webpage.
  • It often works well to provide links to ebrary from behind the secure login of Course Management Systems such as BlackBoard or Moodle. (Note, Canvas is not an option at this point because of its https restrictions).  We would pre-authorize any users coming from http pages behind the login.
  • Important criteria for the webpage/URL to be used as a referring URL:
    • It must be an http URL (not an https URL)
    • It must only be accessible once a user has signed in.  (That is, if you paste the URL into a browser, it won’t take you there; it will either give an error or take you to the login screen)
    • There needs to be a direct link to the ebrary site on the page that’s setup as the referring URL
      • An imbedded URL will not work
      • Do not open the link in a frame or redirected through another URL
      • The link to ebrary needs to come through from the same session and the same window

5. ebrary-hosted Single Sign On, often referred to as RPA (for Remote Patron Authentication):

  • ebrary can host remote access for your ebrary site if you provide us with a file containing either:
    • A unique username and password for each patron
    • Or, a unique barcode for each patron (must be at least 6 digits)
  • This method requires patrons to use that same username/password or barcode to sign in to their personal ebrary account.
  • The library admin sends the list of username/passwords or barcodes to authorize.  The admin can request changes, additions, and deletions over time.
  • Users cannot manually change their own passwords; changes can only be made by the site’s admin, the admin submits changes to
    • This is consistent with industry-standard Single Sign On (SSO) implementations such as Shibboleth, Athens, and EZproxy SSO
  • Note RPA does not work smoothly with IE 10


  • Apache proxy servers DON’T work well with ebrary.
  • VPNs that re-write the URL DON’T work with ebrary.

Admins: EZproxy Single Sign On (SSO)

EZproxy Single Sign On (SSO) works very well with ebrary sites and offers two distinct advantages over a standard proxy approach:

  1. Response time is much better because SSO is a hand-off approach, whereas with a standard proxy approach every command and response passes through the proxy server.
  2. Users have just one username and password to deal with.  Users sign in through your proxy server for both remote access and to sign in to their personal ebrary account.

Three requirements of your proxy server to use this approach:

  1. Your proxy server must require a unique login for each person.  That is, every user has their own username and password or barcode instead of everyone logging on as, for example, “student”.
  2. Once a user logs in through the proxy, a unique identifier for that user must be passed on.  That is, users aren’t all called “cgi-user” or something once they are logged on.
  3. You need to be running at least version 4.0 of EZproxy.

An overview of how EZproxy SSO works:

  • When a user is on-campus, they can access the ebrary site without logging on, but as soon as they try to use a feature that requires them to be signed into their personal ebrary account, we pass them to your proxy-log-on screen.  Once they successfully enter their username and password there, they are passed back to the ebrary screen, and they will have full access to the ebrary site and to their personal ebrary account.
  • When a user is off-campus, they will still use the regular (unproxied) link to access the ebrary site,<YourSiteName>.  The ebrary site recognizes they are off-campus and they are immediately passed to your proxy-log-on screen.  Once they successfully sign in there, they are passed to the ebrary site and at that point they are also already signed in to their personal ebrary account.
  • Note that once EZproxy SSO is in use, users won’t have their old personal ebrary accounts; their ebrary account username will be based on their EZproxy SSO login.   Any users that want the info in their old bookshelf transferred to their new bookshelf just needs to send us their old and new usernames, and we can quickly transfer their bookshelf contents.

Important note:

  • If you are migrating to EZproxy SSO and you have users that had created bookshelves using the prior setup, the contents of those bookshelves will not be automatically transferred over to the new bookshelves.  However, users can email to request their bookshelf contents be copied over; users would need to supply their old username and their new username.  One challenge is that any folders that users might have set up in their bookshelves will not be copied over – all of their bookshelf items will be copied over to the top (uncategorized) level of their new bookshelf.

Setting up EZproxy SSO:

  • To set up EZproxy SSO for your ebrary site, email
  • We’ll make a few changes to your ebrary site’s configuration from our side. To do this we’ll need to know:
    • Your proxy server IP address
    • The URL of your proxy server
    • The version number of EZproxy you are running
    • A temp log-in for your proxy if possible so we can test the setup (just a username/password like a student would get)
  • We’ll send you the specific lines to add to your proxy config file
    • It is important that the ebrary config lines are placed in the config file before any use of AutoLoginIP
    • (AutoLoginIP is used to identify computers that should be automatically logged into EZproxy – and this blocks the process of having on-campus users sign in to their personal ebrary account, which is done via the proxy server)
  • Once both you and we have made the changes, we’ll test and confirm

Admins: Configuration for basic proxy access

ebrary works well with the following proxy servers when configured properly:

  • EZproxy
  • WAM
  • Squid

Configuration Notes

EZproxy with https URL:  we encourage implementing a security certificate such that https protocol is being used.

Add the following 7 lines to your EZproxy config file
NOTE:  replace XXXXX with your ebrary site name

Option DomainCookieOnly

Title ebrary



Find “

Replace “^^/

Option Cookie

Then comment out or remove any previous configs for ebrary and restart your EZproxy server

EZproxy with http URL:

Although not a recommended practice, contact if you choose to implement the non-secure http access

Add the following 5 lines to your EZproxy config file
NOTE:  replace XXXXX with your ebrary site name

Title ebrary



Find “

Replace “^^/

Then comment out or remove any previous configs for ebrary and restart your EZproxy server

The above EZproxy information is for basic proxy access, if you are instead interested in EZproxy Single Sign On (SSO), see:

WAM proxy:

Contact so we can configure for http access

Add this line to your WAM configuration to ensure the links on your ebrary landing page can be used by remote users.   Your WAM foreward table entry should be:


If you don’t use wildcards, you can specify each domain:

Squid proxy:

Needs to be set to not cache control

RPA sign in is not fully compatible with IE 10 (Internet Explorer version 10)

RPA is ebrary Remote Patron Authorization, and is used on some ebrary sites for off-campus access as well as for signing in to personal ebrary accounts.

How to know if your ebrary site uses RPA:

  • If your ebrary site sign-in screen does not say “Please sign in to your personal ebrary account” at the top, but does direct you to if there are sign in problems, it’s likely RPA.

Known issues with RPA when used with the browser IE 10:

  • On some systems, once you sign in, it will not show that you are signed in.  Try clicking on the “Sign In” link again – it may then show you as signed in.

Admins: Shibboleth error “Message rejected, was issued in the future”

If you receive a shibboleth error that ends with “Message rejected, was issued in the future”, it is most likely that the clocks on your various systems need to be synchronized.  The Shibboleth Single Sign On (SSO) system needs the clocks to be within a certain tolerance of each other, or sign-ons do not work.

Upgrading Java on your IdP can be one solution.  The U.S. changed the dates that daylight savings time; newer versions of Java include this change.  See