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

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

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

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

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

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

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

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 Strength vs.

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

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.

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

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

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

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)

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

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?

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

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

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

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