This presentation was provided by Theda Schwing of OhioLink during the NISO Live Connections event, Digital Libraries: Authentication, Access and Security for Information Resources, held on May 22-23, 2018 in Baltimore, MD
2. About our Members
• 121 Member Libraries
• 90 Institutions
• 14 Public Intuitions
• 51 Private Institutions
• 18 Community Colleges
• State Library of Ohio
• Cleveland Clinic
2
3. Current State Summary
• Libraries work with their campus IT staff to purchase and
maintain hardware and software
• Campus IT can play a role in reviewing contracts for library
hardware and software
• Campus IT and libraries work together to handle
authentication problems as they come up
3
6. For the next 30 minutes, let’s assume that there is a
privacy-preserving, secure, alternative to IP
authentication that makes connecting to library
resources intuitive for patrons.
6
7. Some Questions:
1. How do we get from current state to implementing
this standard?
2. What might cause this implementation to fail?
3. Are the considerations different for institutions of
different size?
7
8. Gathering Information
• Survey data from the Survey on
Library Authentication and Technical
Support
• Describes current state of
authentication
• Follow-up interviews with 6
institutions
• 2 small, 2 medium, 2 large
• Limitations
8
9. Small Libraries
9
• The library and campus IT are in one department
• The budget is for the department as a whole
• Regular communication exists between the library and
IT
10. What Could Go Wrong?
10
• Funding might be complicated because IT and the
library share a budget
• Any updated authentication process must fit into the
existing campus environment
• 2-factor authentication, branding, existing library and IT
projects, support for accessibility built in
• Some patron groups might not have campus logins
11. Medium-Large Libraries
11
• The library is in one department, while IT is housed in
another department
• Each department reports up along different lines
• Budgets are separate for each department
• Though separate, the library and IT have a good
working relationship
12. A Slightly Different Set of Problems
12
• IT projects will have to meet that department’s goals – not
the library’s
• The IT department drives its own process & timelines
• Funding is more unclear in this scenario
• Additional complications:
• Multiple directories for different patron groups
• International campuses
13. Large Libraries
13
• The library has its own IT staff, though there is also a
separate, campus-wide IT department
• More dedicated IT staff for the library
• Library IT and campus IT will work together depending
on the scope and focus of a project
14. The Same Problems, Just Bigger
14
• Everything from before is still true – funding will be
complicated, the project needs to fit IT’s existing goals, &
there are many patron types that won’t have network logins.
• Some additional complications:
• Branch campuses, law libraries, medical libraries, and business
incubators
• Relationships with international, very small, and very large vendors
• Internal systems that can have unexpected effects as they are
changed
15. The Special Case of Med Libraries
• Privacy is of particular concern, not just in the library
but to the institution
• Network logins (and what goes in and out of the
network) is tightly controlled
• Patrons can be doctors and nurses in clinical practice
15
16. Some Questions:
1. How do we get from current state to implementing
this standard?
2. What might cause this implementation to fail?
3. Are the considerations different for institutions of
different size?
16
17. How do we get from current state
to implementing this standard?
• It’s going to take an authentication process that has clearly
defined benefits for the campus IT department
• The implementation might need to start with the IT
department, particularly in cases where a library is not able
to initiate a change in technology
• If the new process requires any hardware, software, or staff
time to implement, it will be important to know those costs
up front
17
18. What might cause this
implementation to fail?
• Authentication that doesn’t fit into the exiting campus
environment won’t be implemented
• Authentication that only works with some of a library’s
vendors, particularly if it increases the overall number
of authentication methods a patron might use
18
19. Are the considerations different
for institutions of different size?
• Yes, there are several considerations:
• How the library and IT are related to each other
• The complexity in the patron groups the institution serves
• The complexity of the branch campuses, including medical
and law locations
• The number and sophistication of the vendors with which a
library is working
19
20. Shibboleth in a Box
• Initiative to help Ohio institutions implement Shibboleth
• Many supports in place
• Widely in use
• Central support for implementation
• And yet, there were challenges
• Ongoing local maintenance
• Communication with the library
20
Goal: indicator of library IT independence
Main takeaway – eventhought out of order, its’ the same 4 options
Large institutions buy their hardware directly – have more direct involvement with the technology that is being used inside their own buildings.
Small institutions – have less control over IT equipment. Something that needs exploration. You could draw a conclusion that this is an indication of how much control they have over the set up of that hardware (servers – big example).