This document discusses OpenAthens implementation at Millersville University. It provides an overview of Millersville's needs around authentication and access, the timeline of OpenAthens deployment, how it supports dual-institution programs through attribute sharing between identity providers, working with IT to enable granular usage reporting, and examples of how OpenAthens improved access to resources like ILLiad. Future plans include expanded attribute-based reporting, increased OpenAthens integration across more applications and services, and course-based access through the university's student information system API.

1. What OpenAthens
can do, versus
what OpenAthens
can do for YOU
Scott Anderson, Millersville University
Krista Higham, Millersville University
Amanda Ferrante, EBSCO

2. Agenda
• Millersville University: background, authentication needs
• Conceptualizing an OpenAthens deployment
• OpenAthens (OA) @ Millersville (MVS)
• Timeline
• Working with IT to support access and reporting needs
• Real-world OA example with discovery and item requesting
• Usage reporting: decision-making and customizations
• Specialized database access: limiting user set, time frame
• What’s next?

3. Millersville University: background
• Mid-sized masters level public university + three professional doctorate programs
• ~6,400 FTE (undergrad + grad) / ~300 FTE faculty
• Library houses 280k physical volumes with 335k records in the catalog
o No longer accessioning physical resources except as last resort
• Uses ILLiad, RapidILL, PALCI’s E-Zborrow (OCLC’s D2D; soon to be ReShare)
• Also uses EBSCO Discovery Service

4. Conceptualizing the
set-up
MVS Library needs demanded creative
authentication solutions.
• Dual-enrollment programs
• Reciprocal access, four SAML IdPs
• Goal was true single sign-on
• Granular usage reporting needed

5. OpenAthens
timeline @
Millersville
• Shaping the politics ... throughout 2017
• Canvassing vendors / resources …
spring 2018(ish)
• Squishy launch with selected low impact
vendors in July 2018
• Soft launch through late summer 2018;
did NOT need to flip all resources to OA
simultaneously
• Flipped a high-impact vendor to OA,
tested; waited a
day or two; rinsed and repeated

6. OpenAthens
timeline @
Millersville
• All resources set up by end of first week
(yep, students were already on campus)
• Left deprecated proxy service running
during launch to support stray links,
things we skipped (such as journals
and eBooks in catalog)
• Flipped ILLiad, Ares, Aeon services in
spring 2019 (yes, it really works...)
• Atlas Systems applications: ILLiad, Ares,
Aeon, ArchivesSpace
• All hosted by Atlas for Millersville

7. Dual institution
programs
• Four master’s and doctoral programs with three other
institutions
• Kutztown, Shippensburg, and West Chester Universities
• All use OpenAthens; IT does not need to establish ”trust
relationship”
• Users choose where to log in; can access either library's
subscriptions with valid credentials
• Works around siloed institutional business logic
• OA does the “logic check,” looking for agreed-upon attribute
• If KZS student knocks at MVS, MVS OA is looking for
appropriate attribute (visuals to follow)
• Attributes assigned by KZS to KZS dual institution student,
MVS does same in their IdP (visuals to follow)

8. Building the solution:
dual institution programs
• Four IdPs: MVS, SQP, QWC, KZS
• Development undertaken by
OpenAthens to support duplicated
SAML IdP connections in each
school's OpenAthens domain
• OpenAthens-hosted IdP for
walk-ins, temporary guest users

9. Building the solution: dual institution programs
• Each site committed to establishing a
data attribute that allows OpenAthens
to identify dual-institution users
• Rules established in OpenAthens
settings to restrict access to
unauthorized users

10. Working with IT to
enrich reports & access
• Understand the politics of the process of internal
university business logic
• Who is a dual institution student enrolled
in a given dual institution program?
• … which is hard to answer when “who is a
student?” isn’t always obvious
• Example: No single person at Millersville
knew the entire process for “accounts”
• IT doesn't really know much about users (in AD);
the provost knows a lot about users (in Banner)

11. Working with IT to
enrich reports & access
• Moving data around to authenticate
• MVS IT exposes attributes via Millersville’s IdP
• Banner SIS 8 MVS AD 8 MVS IdP 8 OpenAthens
• Data feed is cumbersome and sluggish
• Exploring OA query of Banner via API for course
data in real time
• Scoped access “by course” to niche products
• BONUS: IT needs to make ONE connection to OA,
configure ONE key for Banner API connectivity?

12. Building the solution:
reporting What?
Granular usage reports with actionable,
relevant, current data breakdowns
How?
Identify datasets needed by the library; work
with IT to have relevant attributes released to
OA
Why?
Supporting dual-institution visibility; informing
library decision-making.

13. resource usage
by user group

14. usage broken
down by academic
major

15. usage broken
down by academic
minor

16. An exemplar … a quick trip ...

17. Building the
solution: logging into
services
• SAML access configured to tools and applications that
require personalization
• Reporting for ILLiad, Ares, Alma/Primo access became
available
• ILLiad usage data lead to conversation about ILL custom link
UX

18. ILLiad log-ins:
before and after
• Request this item …
the “green squirrel”
• Before OpenAthens
• Forced another user login to ILLiad. Why
keep forcing logins?
• Login to ID the user. We can accurately
associate request and user with OA.
• After deploying OpenAthens
• Find item & click “Request this item” ILL
form populates without user logging in
again
• Next step, “white rabbit”
• The logic associated with the custom link
tests for metadata “sufficiency”

19. ILLiad log-ins:
operational logic
Insufficient request metadata present
• Missing ISSN and publication year, for
example
• ILLiad request form presented by request
type (e.g. returnable, not returnable)
• User provides missing “required” elements
• They gotta find these someplace else,
because the citation is lacking
• Submits request as in the olden days —
that’s so last year

20. Improved logic with
OpenAthens
Sufficient request metadata present
• Previously what we called "required" on the
form
• Request passed via ILLiad API; "thank you for
your request"
• No user review required
• User has no chance to review anything pre-submission
• Less than 4% of requests had any "notes"
• Less than 1% of requests had useful "notes“
• Duplication request checking
• Blocked from placing the same request twice in one
session

21. Niche
(/niCH,nēSH/)
database access
• Relating to products, services,
or interests that appeal to a
small, specialized section of the
population
• Things we’re pursuing:
• Course- and semester-based
access to resources
• Major/program access
to resources (PhD students in
programs X, Y, Z get access to)
• Access by user type (“Inspec for
faculty,” “Headbanging for tall
students”)

22. What's next?
• Expanded attribute-based reporting: facultyDepartment, major
• Increased OpenAthens saturation & utilization: the last apps & new
utilizations
• TIND IR/DA, Project ReShare (unmediated resource sharing), last proxy
resources/services
• Course-based access via Banner API
• Keep the conversation with IT going
• Moving to Azure AD? What data is available there? Skip the MVS Shib?

23. Questions?
Scott Anderson
Information Systems Librarian, Millersville University
scott.anderson@millersville.edu
Krista Higham
Access Services Librarian, Millersville University
krista.higham@millersville.edu
Amanda Ferrante
Product Manager, Authentication Solutions, EBSCO
aferrante@ebsco.com