Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    360 Search: Authentication Options

    • Product: 360 Search

    How can I provide user authentication into 360 Search?

    Like other subscription resources, 360 Search can only be accessed by authenticated users (patrons). Local users (in your IP range) will normally authenticate directly via IP authentication when they click the 360 Search URL. Remote users must authenticate in one of four ways to access the interface: via a proxy server, a single username/password pair, referring URL, or single-sign-on (SSO) with Athens or Shibboleth. User authentication for 360 Search is enabled through the User Authentication Administration Console.
    Supported methods for configuring access into 360 Search are detailed below. In each case, use of the Authentication Settings within the User Authentication Administration Console is required. We provide instructions on Authentication Settings here:
    1. Proxy Server: The vast majority of libraries with 360 Search use a proxy server to provide remote access to the 360 Search interface and the results. You can set up by adding 360 Search to your proxy's configuration file, making sure your proxy's IP address is entered in the User Authentication Administration Console IP address section, and then posting a proxied link on your website. When users click on the proxied link to 360 Search, they will be directed to your library's proxy login screen. Once they log in to the proxy, they then essentially have IP authentication (using the proxy server's IP address) to both the 360 Search interface and to the search results. This method allows users to freely conduct searches and access content without any further login requests. Here are two documents covering specific proxy types:
    2. Referring URL: Referring URL authentication for 360 Search is a two-step process. First, the library posts the link to 360 Search on any page, and then enters the URL of that page in the User Authentication Administration Console Referring URL section to use as an approved "referrer." Users who click on the 360 Search link from that particular web page will automatically be authenticated to the 360 Search interface. Next, the library must contact each of the vendors (providers) of the databases in 360 Search and ask the vendor to add the 360 Search URL as an accepted "referrer" on the vendor's end for authentication. Once that is done, the vendor recognizes and authenticates any user who is linking to their results via 360 Search.
    Some vendors don t support Referring URL authentication. Be sure to check with your database vendors to confirm their support for Referring URL authentication before choosing this method.
    3. A Combination of Proxy Server and Referring URL Authentication: Libraries that wish for the users to access the 360 Search interface without authenticating, and only be prompted for a proxy login when they attempt to access the native resources' interfaces, can use the two models above together. First, set up referring URL authentication to get the users in to the 360 Search interface, then apply your proxy syntax to all of the database-level and article-level links. Users will access 360 Search and issue a search without authenticating, then they will be prompted for a proxy login when they click the database-level and article-level links. Users will only need to log in to the proxy once during the search session.
    To set this up, enter the Referring URL in the User Authentication Administration Console as described above as the accepted referrer, and make sure that your proxy's URL is in the Library URLs section of Library Settings in the Client Center. You will also need to make sure that the "Library Proxy" checkbox on the Database Details page for each database you include in 360 Search is unchecked; this step ensures that our system will automatically prepend your proxy URL to 360 Search results.
    An important consideration if you choose this combination is that this seemingly "open access" model of searching the databases' content before authenticating may violate some vendors' terms of use. Please check with your database vendors to make sure you are abiding by your subscription agreement in implementing this option.
    4. Username/Password: As an alternative, you may set up a single username and password of your choice in the User Authentication Administration Console for authentication into 360 Search. Remote users will be prompted to enter that username/password when they click the link to 360 Search. Your library must communicate the username/password to your users, and remote users will also be prompted for a vendor-specific username/password when they click the result links.
    5. ILS Based: In this context, ILS-based authentication refers to the practice of using a library's ILS for authentication of a patron before allowing the patron to use 360 Search. The User Authentication service has been qualified for use with several different ILS systems, including III Millenium, but if you use a different ILS, it may work anyway. Let us know (using the Support Portal option menu near the top of this page) if you successfully use a different ILS for User Authentication.
    6. Token-Based: Users enter their username and password in order to obtain a "token," which allows them to fetch resources without using their username and password again. Libraries that wish to use Token-Based Authentication should contact Serials Solutions for assistance using the Contact Us menu near the top of this page.
    7. Athens/Shibboleth: When 360 Search is set up as an Athens or Shibboleth-protected service, your library can prompt users to enter their single sign-on (SSO) login information in order to use it. Once the users have logged into Athens or Shibboleth, they can access 360 Search, conduct their searches, and see results that are returned. When users click on a result link, they should be passed straight through to the item without further challenge, provided the database from which the result came is also SSO-enabled.
    Athens configuration requires that you choose Athens/AthensDA as your remote authentication method in the User Authentication Administration Console and that you add your library's Athens Organisation ID in the field provided.
    Shibboleth configuration requires that you choose Shibboleth as your remote authentication method in the User Authentication Administration Console and that you add your library's Entity ID or link to your library's Identity Provider (IDP) metadata in the field provided.
    Users who click on links to other resources or services that are Athens- or Shibboleth-protected from within the same browsing session will not receive another login prompt and will be able to move freely between the protected entities.

    • Date Created: 9-Feb-2014
    • Last Edited Date: 28-Feb-2014
    • Old Article Number: 7419
    • Was this article helpful?