Patron Verification and Security The Web OPAC and Beyond. Richard Goerwitz Carleton College

Transcription

1 Patron Verification and Security The Web OPAC and Beyond Richard Goerwitz Carleton College

2 Who am I? I work primarily in higher education University of Chicago Brown University Currently at Carleton College Support key higher-ed technologies Web-based services Databases Work closely with libraries on Remote-access issues (proxies) Authentication

3 What is This Talk About? Foremost, this talk is about Online patron verification Otherwise known as authentication By the end, you'll grasp terms like Authentication LDAP Shibboleth You also grasp how to use these things to: Simplify and secure patron access Get yourself largely out of the password-maintenance business

4 Online Patron Verification Online patron verification A library-specific term A broader, better term is authentication Authentication means Verifying that something is genuine or authentic In an IT context, it means Verifying that someone is who he or she claims to be 'To authenticate' (vi.) means To prove you are who you say you are

5 How Do You Prove You Are Who You Say You Are? Via one (or more) of three methods: Via something you are - biometric Fingerprint Retinal vein pattern Voice recognition Via something you have - token-based ID card License Via something you know - password-based A password

6 Biometric Authentication Strongest authentication method Requires fancy hardware Fingerprint readers Retinal scanners Voice recognition Too expensive for libraries Totally unworkable for OPACs Proxy servers Anything we expect people to access outside the library

7 Token-Based Authentication Inconvenient Tokens must be carried around In a purse In a wallet Not always handy Weak, as tokens may be lost stolen, or wear out Sub-optimal for online resources

8 Password-Based Authentication Used for most online resources Weaker if users - Choose bad passwords, or Write down passwords Stronger if users - Choose good passwords and Don't write passwords down Convenient if users - Choose bad passwords, or Write down passwords Convenience vs. Strength

9 Convenience vs. Strength Should we actually care about authentication strength? Depends on how much you care about: Protecting copyright Complying with license terms Analyzing usage patterns, statistics Collecting usage fees I will assume you want strong security, if you can get it - Cheaply In a way that's convenient for patrons

10 The Problem Our challenge, then, is to find a method of enforcing passwords that are Secure/tough to guess, BUT Convenient/easy to remember In order for this method to be cheap, it must also tie easily into all electronic services: OPACs Proxies OpenURL resolvers ILL systems, etc.

11 The Solution The solution to our problem lies in centralization You must tie all your electronic services to a single (existing) authentication provider Make one password fit all services Reduce maintenance/increase convenience Passwords can be changed centrally People have just one password to remember To do this, your services must all speak a common language: LDAP

12 LDAP Lightweight Directory Access Protocol LDAP is a language for talking to a directory E.g., What is this person's name? Is the password he/she provided correct? Most operating systems can talk LDAP Windows + Microsoft Active Directory Netware + Novell NDS/eDirectory Library systems can talk LDAP, too Ergo: LDAP may be used to authenticate library patrons centrally

13 How Does This Help Me? Millennium now comes LDAP-ready Ergo, if you're a Millennium site you can authenticate patrons using your existing LDAP services Advantages: Easy/cheap to implement Allows patrons to re-use existing institutional passwords (making them easy to remember) Leverages password-strength enforcement that's already in place

14 How Else Does This Help Me? Various other electronic resources can also leverage LDAP Proxies (e.g., EZProxy) ILL (e.g., OCLC Illiad) Enterprise digital asset management tools Ex Libris DigiTool Cumulus Canto Image management tools ContentDM (full LDAP support in next release) Luna Insight (partial)

15 But, but... (1) But I don't know anything about LDAP Ask your network administrators But my network administrators don't know anything, either Train them Hire a consultant Have III help you out But my OPAC serves multiple institutions Millennium supports plug-ins that allow it to talk to multiple LDAP servers

16 Electronic Resources and LDAP Can vendor electronic resources use LDAP? Simple answer: No Fortunately, if patrons are on-site, they don't need to authenticate in order to use most electronic resources But off-site patrons must use a proxy Problems with proxies Require maintenance Require special links on your web site Slow down patron access to electronic resources So: Can we reduce the need for proxies?

17 Reducing the Need For Proxies Will be done with services like Shibboleth Shibboleth serves as an intermediary between Your local security provider (e.g., LDAP) and Your vendor/aggregators' off-site systems Provides a way for off-site systems to authenticate patrons without Having to use a new set of username/passwords Having to go through a proxy Reminiscent of Microsoft's Passport service

18 Who Makes Shibboleth? Shibboleth is a project run by Internet2 (I2) Higher-ed technology consortium Open to government/industry partners/affiliates An I2 Middleware Initiative project Funded by the National Science Foundation (NSF) Also funded by member institutions, partners Gaining support among vendors Aggregators (Ebsco, Lexis Nexis, etc.) OPAC, OpenURL vendors (particularly Ex Libris) Not viable yet; stay tuned

19 So What Have We Learned? We've learned a few cool terms/concepts: Authentication, LDAP, Shibboleth We've also learned that by centralizing authentication using (potentially already existing) LDAP-enabled systems we: Reduce password/pin maintenance burdens Reduce the number of passwords patrons need to remember Reduce patrons' tendency to write down passwords Pave the way for things like Shibboleth

20 Conclusion There is an emerging new order in which libraries are Leveraging existing LDAP services to Allow patrons to use existing usernames/passwords Get out of the password-maintenance business, mostly In the new order, LDAP services are Facilitating test Shibboleth deployments These Shibboleth deployments will ultimately Allow us to reduce reliance on proxy servers Simplify patron access to remote resources Speed up access