Controlling Access to Resources for Walk-In Users 14 September 2006

1. Controlling Access to Resources for Walk-In Users14 September 2006 Rod Crowley Systems Team Leader Leeds University Library

2. Summary • Exploration of how Leeds solved the knotty problem of regulating access to our online resources for our external users. • Not advocating that this is the only possible solution – just a neat one which works for us

3. Context in 2004 • 150 Library Internet PCs • User authentication not required • All people permitted access to our buildings could access the Web • Included c12,000 external users • And a number of day visitors • But the system basically worked

4. What changed? • Growing number of incidents of computer misuse • Clarification at University level of the requirement to authenticate

5. LEEDS UNIVERSITY ACCESS CONTROL & ACCOUNT MANAGEMENT POLICY 2.5 Identification and Authentication All users of University systems must be identified and authenticated by systems that they access using at least two sources of information. Prior to using University systems, users must: 􀂾 l Present their identity to the security mechanisms of the system by entering a user-id or user-name that has been allocated to their computer account, or by presenting some other form of system recognised identity; and, 􀂾 l authenticate themselves by providing information, such as a password or PIN, that the system corroborates as a binding between the person and the identifier, and validates them as being an authorised user.

6. What changed? • Growing number of incidents of computer misuse • Clarification at University level of the requirement to authenticate • Guidance from CHEST and JISC about the University’s responsibilities

7. CHEST Public Access and Library Terminals Use - Definitions Walk-in User A person who is not a currently registered student, faculty member or employee of the licensed institution but is permitted by the institution to access the secure network* via a computer or terminal within the Library premises is deemed to be an authorised user but only for the duration they are within the Library premises. Institutions that provide access to networks, and users who benefit from that access, should regard it as normal to require an individual identity. Secure Network shall mean a network (whether a stand alone network or a virtual network within the Internet) which is only accessible to Authorised Users whose identities are authenticated by the Institution at the time of log-in and periodically thereafter consistent with current best practice and whose conduct is subject to regulation by the Institution. (http://www.eduserv.org.uk/chest/datasets/walk-in-users.html)

8. What changed? • Growing number of incidents of computer misuse • Clarification at University level of the requirement to authenticate • Guidance from CHEST and JISC about the University’s responsibilities • Dawning realisation within the Library that the status quo was unsustainable.

9. Possible Options Option One • Require a University Login to all Library PCs but… • ISS not willing to register 12,000 new users • Library unable to withdraw access for these users

10. Possible Options Option Two • Issue a Generic Login to External Users from our Counter but… • Time consuming to administer • Inconvenient for our users • What about when the Library is unstaffed?

11. Possible Options Option Three • Forget about users logging in and instead run an extensive CCTV system overlooking the Library Intranet PCs but… • Very expensive • No authentication of PC users • Therefore failed to meet the minimum institutional and national standards

12. Possible Options Option Four • Authenticate our users using a third-party product (CybraryN) linked to our Innovative system via the Patron API interface • Reasonable cost • Track record of Innovative integration • Achieves authentication for all Library users • Permits access whenever the Library is open • Minimal administration • Meets national and institutional standards

13. How Does It Work : Out of the Box

14. Issues to Overcome • Patron API Security Hole • Notoriously insecure • Confidential data sent over the network • IP address restriction not effective • Threat of data harvesting

15. Issues to Overcome • Patron API Security Hole • Consistency with WAM • Had recently been introduced • CybraryN more stringent • WAM more forgiving • Wanted to avoid user confusion

16. Issues to Overcome • Patron API Security Hole • Consistency with WAM • Logging of usage data • Pattern of ‘external’ PC use a mystery • Collecting data from individual PCs inefficient • Central log of usage preferable

17. Issues to Overcome • Patron API Security Hole • Consistency with WAM • Logging of usage data • Limitations of CybraryN software • Product designed to work with various LMS (including Innovative) • An alternative setup required development work by CybraryN themselves

18. Middle Service Based Authentication

19. Middle Service Key Points • Simple CGI Script written in Perl using existing modules • Sits on the University’s main webserver • Configured so that the CybraryN client thinks the Middle Service is a web page • While WAM treats it as a web browser making a WAM request • All requests logged on the webserver – successful or not • Log can be used for troubleshooting or for usage statistics

20. Implementation • Introduced in Summer 2005 in our six campus Libraries • Our Main Libraries began with four CybraryN PCs each • Health Sciences Library began with fourteen • External members can use their name and Library barcode to authenticate themselves • Day visitors have to produce ID and sign the University’s Acceptable Use Policy in order to receive a day ticket • Has proved very nearly trouble free

21. And finally… Any Questions? • If you are interested we are happy to answer further questions, share the script and provide implementation advice. • But we cannot offer ongoing support • Contact : r.crowley@leeds.ac.uk