Please note that addresses of the type 10.*.*.*, 172.[16-31].*, and 192.168.*.* are reserved for use in internal networks, such as computers that are behind a firewall or a proxy server, and are not useful for authentication purposes.

Whenever your institution makes any changes to the IP addresses it uses to access JSTOR, you can submit these updates to JSTOR Support.

All participating institutions have the option of setting up remote access to JSTOR for their users along with onsite access. The main methods of remote access that we support are proxies, federated options like Athens and Shibboleth, and shared activation links. We do offer several other remote access options when the main supported methods will not work for your institution. Please contact JSTOR Support for assistance selecting and setting up the best remote access method for you.

You are welcome to authenticate users to JSTOR through a proxy server, as long as access to the proxy server is restricted to only authorized users at your institution. On our end, the only configuration necessary would be to ensure that the IP address for your proxy is enabled to access JSTOR. In order to enable a proxy server for your institution, please submit your proxy server IP address to JSTOR Support.

In order to enable your JSTOR access via EZProxy, all we typically need from you is the IP address of your EZProxy server. Feel free to send it to JSTOR Support and we will make the necessary changes.

OCLC's support team should be able to help you with your EZProxy set-up, however the configuration we typically recommend for JSTOR access is as follows:

1. The JSTOR database definition should be:

Option DomainCookieOnly

Title JSTOR

URL http://www.jstor.org/

Domain jstor.org

Option Cookie

2. In addition, EZProxy must be explicitly configured to handle https. If https handling is not already set up, users will lose proxying when they arrive at the JSTOR login page, and the connection will be lost. If this is the case, SSL configuration must be performed using the information provided by OCLC.

JSTOR supports authentication through both the OpenAthens MD and OpenAthens LA services. Once we have enabled OpenAthens authentication for your institution, users will be able to access JSTOR by signing in through with their institutional login from the JSTOR login page.

OpenAthens MD is a centrally hosted identity management service available through Eduserv, and you can read more about it on the Eduserv website. To enable access to JSTOR through OpenAthens MD, the JSTOR resource must be allocated as a resource for your institution. Please contact JSTOR Support to request that we enable OpenAthens MD as your access method and include your Org ID in the request.

OpenAthens LA is a locally-hosted single sign-on (SSO) service, and you can read more about this service on the Eduserv website. JSTOR partners with OpenAthens-enabled institutions to allow users to access JSTOR by signing in with their institutional login from the JSTOR login page. If you would like to enable access to JSTOR through your OpenAthens LA identity, please contact JSTOR Support with following information:

+ Your institution's Shibboleth Identity Provider ID

Once this information is in our records, your Attribute Authority can authorize users into JSTOR by asserting the eduPersonEntitlement attribute with a value of urn:mace:dir:entitlement:common-lib-terms.

Shibboleth is open source software that provides institutions with Single Sign-on, a system of authentication procedures, protocols, and technologies that enable end users to access multiple online resources with one set of credentials. The Shibboleth system allows organizations to exchange information about users securely and privately. More detailed information may be found on the Shibboleth website.

JSTOR partners with Shibboleth-enabled institutions to allow users to access JSTOR by signing in through their institution from the JSTOR website. However, in order for an institution or organization to access JSTOR through Shibboleth, JSTOR and the organization must be a member of the same Shibboleth federation. A list of federations may be found on the Shibboleth Federations website.

If you would like to enable access to JSTOR through your institutional Shibboleth identity, please contact JSTOR Support with following information:

+ Which federation (or federations) your institution is a member of

+ Your institution's Shibboleth Identity Provider ID (entity ID)

+ The list of campuses (if more than one) the Identity Provider serves

Once this information is in our records, your Attribute Authority can authorize users into JSTOR by asserting the eduPersonEntitlement attribute with a value of urn:mace:dir:entitlement:common-lib-terms​.

Please note that while JSTOR is currently a member of the following Shibboleth federations, we'll be happy to explore joining other federations as necessary:

+ DFN-AAI
+ InCommon
+ SWITCHaai
+ UK Access Management
+ OpenAthens
+ eduID.cz
+ SWITCHaai

A shared activation link allows an individual's MyJSTOR account to be connected with their institutional affiliation. It also provides an elegant access option for small institutions and those with limited technical infrastructure or IT resources. Just a few steps are needed to set up access with a shared activation link, described below.

1. JSTOR Support sends an email with the link and instructions for you to share with your institutional users. The link looks something like this:

2. A user follows the link and lands on the MyJSTOR Registration page, where they are prompted to register for a personal MyJSTOR account.

3. After filling out the registration page, they will see a confirmation message that confirms their access. Notice at this stage that they see a Provider Designation Statement for your institution (circled in red) where none was displayed before.

For all future visits, users can go directly to JSTOR from anywhere without using the shared activation link. When they login to their MyJSTOR account, they will have access to both the citation management benefits of a MyJSTOR account and the full-text access of your institutional participation.

You are free to distribute the provided link to authorized users at your institution with the understanding that it would be for their exclusive use. If you maintain a password protected site, this would be an acceptable location to publicize the JSTOR shared activation link and instructions. However, please note that the link itself must not be posted on public web pages, where it might become available to unauthorized users.

To set up a shared activation link for your institution, please contact JSTOR Support.

JSTOR’s Institution Finder assists unauthenticated users at your institution to access full-text content on JSTOR. Here's how it works:

1. A user arrives on a JSTOR article page from a Google search or other referring page

2. An on-campus user will get automatic access to the full-text, but users outside of the institution’s IP range will be denied access

3. When denied access to the full-text, the user is presented with options for accessing JSTOR, including a link to the JSTOR login page and the Institution Finder

4. From there she can search for their institution and follow a link to your proxy login page

5. After logging in, she is authenticated to JSTOR and will be automatically redirected to the original full-text article

If you are interested in this functionality for your library, we need only to confirm your EZProxy prefix, which should look something like this:

http://server.university.edu/login?url​=

You can send this information to JSTOR Support.

We are able to support referring URL as an authentication method to JSTOR under the following circumstances:

-The referring URL must be password-protected, meaning users must authenticate in some way in order to gain access to the referring page, via username and password, library number, barcode ID or similar.
-The referring URL begins with http, as opposed to https, which won’t work for JSTOR authentication.
-The referrer does not include embedded code (such as JavaScript) to open a new window.
-Users do not have security software on their computers (personal firewalls and the like) that strips the referrer information from the headers. In these cases, referring URL authentication will not work.
-Sometimes library server configurations on a website result in the HTTP referrer header not being sent. If this is the case on your website, then referring URL authentication will not work for any users.

If these conditions are possible and you would like to explore whether referring URL will work as an authentication method for your library, then all we typically need is the referring URL itself, i.e. the URL of the page that includes the link to JSTOR. Referring URLs often look something like:

Please note that referring URL is not a fully-secure authentication method as the referrer can be manipulated in the HTTP header (at least one Firefox extension exists to do just this). It is important that participating institutions ensure that only authorized users are allowed access to JSTOR. Please contact JSTOR Support for assistance with setting up referring URL authentication for your institution.

It is necessary for your browser to be set to accept cookies in order to browse and search the JSTOR site, as well as to improve the response time and performance of the site. Click here for instructions on enabling cookies in your browser. Any personal information, other than what is voluntarily submitted, is not extracted in this process, and we do not use cookies to identify what other websites or pages you have visited. Please visit the page on JSTOR’s Use of Cookies for more information.

All Rights Reserved. JSTOR®, the JSTOR logo, JPASS® and ITHAKA® are registered trademarks of ITHAKA.