Shibboleth Implementation in EZproxy By Todd Wallwork Systems and Technical Services Librarian University of Alabama Libraries ER&L Conference 2018

What is Shibboleth? Open source software package for web federated single sign-on (SSO) Uses SAML (Security Assertion Markup Language) Federated SSO means that the service provider (SP, UA Libraries) can work with more than one Identity Provider (IdP) and vice versa regardless of whether they are in the same organization More about Shibboleth https://www.shibboleth.net/index/ https://www.shibboleth.net/index/basic/

Why move from LDAP to Shibboleth? Single sign-on (SSO) Security upgrade and possible DUO two-factor authentication integration DUO: two-factor authentication service DUO still not enabled for Shibboleth services at UA DUO must be enabled for all Shibboleth services (over 100 on campus) or none at all Still uses the same LDAP data store/settings and University feeds we were using Additional benefit: Shibboleth attributes for grouping, limiting access to resources, study rooms, etc.

Who was involved? Library Systems (myself and a Tech Specialist) Library Head of Web Services (facilitator) Campus IT: Shibboleth administrator and our server administrator Library Administration Resource Acquisition Discovery (RAD) Administration (my department)

What resources were used? EZproxy documentation EZproxy Shibboleth Authentication page Notably Quick Configuration steps Common Conditions and Actions page Shibboleth Consortium webpages Shibboleth administrator and server administrator’s knowledge and feedback EZproxy Listserv and community members Other sites that helped clarify EZproxy Quick Configuration steps https://edugate.heanet.ie/rr3/p/page/ezproxy

What steps were taken? Internal Library communication to begin project Library Administration, RAD administration, Library Head of Web Services, Library Systems Reviewed EZproxy Shibboleth Authentication documentation Opened communication with campus IT Library Head of Web Services, Shibboleth admin, EZproxy Server Admin, Library Systems Followed the Quick Configuration steps on the EZproxy Shibboleth Authentication page https://www.oclc.org/support/services/ezproxy/documentation/usr/shibbole th.en.html#quick Redesigned the e-resources login and blocked login pages (Library Systems: Tech Specialist)

Shibboleth Implementation Challenges and Solutions EZproxy, Shibboleth, and other related documentation is ambiguous in some areas and give few examples Some possible conditions not listed in EZproxy Documentation Example: IfCount condition Somewhat understandable given local variation but still an issue Example: “your-entity-id-here” and “EZproxyEntityID”

Shibboleth Implementation Challenges and Solutions Syntax differences between EZproxy documentation and local IdP configuration Syntax found in EZproxy documentation unusable due to local IdP configuration. Logging usernames in Audit log EZproxy documentation included the following line to log usernames Set login:loguser = auth:urn:mace:dir:attribute-def:eduPersonTargetedID eduPersonTargetedID attribute not supported by our IdP eduPersonPrincipalName used instead Block patrons on Shibuser.txt If auth:eduPersonPrincipalName eq “username"; Deny deny.htm (did not work) If login:user eq “username"; Deny deny.htm (did not work) If auth:eduPersonPrincipalName eq “username@ua.edu"; Deny deny.htm (worked)

Shibboleth Implementation Challenges and Solutions Differences in the Shibuser.txt and User.txt files? Shibuser.txt: patron blocks; country block exceptions; country blocks User.txt: temporary accounts; admin accounts Logging usernames in audit log After initial configuration, all users logged as username=Shibboleth Based on EZproxy Listserv recommendations, following added to shibuser.txt file: Set login:loguser = auth:eduPersonPrincipalName Set Login:user = auth:eduPersonPrincipalName

Shibboleth Implementation Challenges and Solutions Non-UA affiliated authentication? Cannot locally authenticate nonaffiliated patrons (including temporary logins, admin logins, etc.) through the Central Authentication Service (CAS) login page Solution: two login forms; One for nonaffiliated patrons Link to the CAS login page for UA affiliated patrons Some extra work created in the form of failed logins and login problems Added benefit: fraudulent logins have fallen substantially

UA E-Resources Login page

Shibboleth Implementation Challenges and Solutions After going live, minority of usernames not logged (audit log) Fundamental misunderstanding of how the UA Shibboleth IdP authenticates in relation to patron LDAP entry Library tag present in LDAP record=username communicated (authorized) Library tag not present in LDAP=username not communicated (unauthorized) Needed way to deny access those usernames not communicated back to EZproxy Solution: add following to shibuser.txt If Count(auth:eduPersonPrincipalName) eq 0; Deny loginbu.htm

Shibboleth Implementation Challenges and Solutions Logging failed logins from Shibboleth Shibboleth does not communicate failed login data when username/pw does not match Shibboleth does pass all but the username when a user is denied because a patron does not have the library tag in LDAP Other information including IP address, timestamp, etc. can be useful No resolution yet scripting the capture and communication of that data possible (have not pursued) Lack of developer on staff i.e. probably need to contract out this process

Shibboleth Authentication Workflow (UA-affiliated patron) Off-campus user clicks link on library resource User directed to UA Libraries E-Resources Login page (EZproxy) If UA affiliated; user clicks on Login using your myBama ID link User directed to IdP IdP directs user to CAS login page where they enter their credentials If user’s credentials are correct, IdP checks LDAP for user and library tag If user is in LDAP and has library tag, user’s attributes and username are transmitted back to EZproxy, i.e. authorized. User is sent onto to library resource

Impact on other Shibboleth services? SpringShare LibCal – used by UA Libraries for study carrel booking Wanted: limit study carrels to Faculty and Graduate students Local Shibboleth IdP not configured to communicate student’s status as either graduate or undergraduate Needed attribute: eduPersonScopedAffiliation Worked with Campus IT, Library Springshare admin, and Registrars office to have graduate/undergraduate status made available for Shibboleth Refworks Shibboleth SSO Assisted Library Web Technologies and Development with Shibboleth configuration My role: sharing related Shibboleth configuration experience

Shibuser.txt syntax examples Logging users: Set login:loguser = auth:eduPersonPrincipalName Set Login:user = auth:eduPersonPrincipalName Denying users without library tag If Count(auth:eduPersonPrincipalName) eq 0; Deny loginbu.htm Blocking patrons If auth:eduPersonPrincipalName eq “username"; Deny deny.htm Country block exceptions If auth:eduPersonPrincipalName eq “username@ua.edu"; Stop Country Blocks IfCountry US; Audit Blocking United States; Deny loginbu.htm

Best practices/Lessons learned Reach out as early as possible to IdP for local policies/configurations and list of attributes they release For someone new to these concepts, research Shibboleth, SAML, EZproxy authentication methods, etc. Document the implementation process What worked What didn’t work

Thank you! Questions? Todd Wallwork System and Technical Services Librarian University of Alabama Libraries tmwallwork@ua.edu