JSTOR as a Shibboleth Target David Yakimischak davidyak@jstor.org

Agenda JSTOR Overview Auth/Auth Past IP Addresses JSTOR needed a solution Motivation to change Some ideas to accelerate change Discussion

JSTOR Mission JSTOR is a not-for-profit organization with a mission to help the scholarly community take advantage of the advances in information technology. This includes: (1) building a reliable and comprehensive archive of core scholarly journals, and (2) dramatically improve access to this scholarly material In pursuing its mission, JSTOR takes a system-wide perspective, seeking benefits for libraries, publishers and scholars

JSTOR Today 2,105 participating libraries 264 participating publishers 419 journals online 15,342,964 pages scanned (and counting!) Access is at least 10x greater than paper (major benefits are full-text searching and access from outside of the physical library)

JSTOR Monthly Usage Meaningful Accesses

Auth/Auth Past Authentication Scheme Concerns IP Address Identifies machine, not user; Not secure (at all) Username/Password Management nightmare; Users dislike them Athens Too unique (U.K.); Too centralized X.509 Too complex; Browser-based

90%+ of Auth is IP Addresses It identifies the machine, not the user Problems when user is off-campus (proxies) Problems with NAT, DHCP, firewalls Proxies (especially open) are a problem But it is simple and it works Each resource maintains its own database

JSTOR needed a solution Shibboleth appeared to have the right characteristics Implementation was easy; it worked Fortunately we had previously separated authentication and authorization Pilots are working very well

Identity Metadata Currently we accept the eduPersonAffiliation attribute and map that to what we call a ‘site’ Some problems with mapping when one eduPersonAffiliation maps to more then one JSTOR site Have not yet experimented with entitlements Federations are helpful but we don’t need a lot of them

Motivation to change It’s either got to be better or cheaper (or both) Ability to enforce current licensing agreements and support new models Cost-effectiveness from this and Lower cost of support (e.g. IP databases) Universal standardization

Some ideas to accelerate change A resource provider might issue a challenge to the community to stop using IP address authentication Lower access fees? How about a charge for using IP addresses, or a charge to make changes? Point solutions: portals, metasearching, remote access Username/passwords can become a Shibboleth origin at JSTOR Same for IP address authentication Central IP address registry as a migration mechanism to Shibboleth

Discussion