==== DRAFT / WIP ====
DEMO for the Super Walk-In Users Portal - LIbrary Pilot # 1 - Scenario 3
Two major obstacles preventing University libraries from moving to all-federated access are both IP addresses.
Some service providers only support IP addresses for "authentication". This can be resolved using EZProxy to bridge between modern federated authentication and legacy eresources using IP-address authentication.
Libraries currently use IP-address based authentication for providing access to "walk-in" library users. Walk-in users are people who do not have institutional IT accounts (and so cannot use normal IdPs) but who can access eresources by visiting a library and using terminals. Eresources will normally grant access to these terminals by relying on IP address authentication.
Problems with the IP address Kiosk approach
Requires all eresources (potentially a large number) to be configured with the IP addresses of all kiosks. Adding a new kiosk will be awkward and time-consuming.
Deprovisioning the IP addresses of networks or individual kiosks can be easily overlooked, creating potential access problems
Continuing to rely on IP addresses to access eresources will hold back progress
Using IP address authentication at the institutional IdP
The Shibboleth IdP can be configured to automatically authentication users logging in from defined ip addresses or ranges of ip addresses. This can be used to provide modern, federated access to eresources for walk-in users at library kiosks.
However, this approach has a few disadvantages:
The configuration is via XML files, and the IdP needs to be restarted to load them. Library staff cannot easily make changes or see the current status
Not all libraries are have available SAML IdPs
Pilot Solution: A shared, easily configured IdP service for Walk-In users
A standard Shibboleth IdP v3 was used
Authentication was configured to only use IP addresses, and all IP addresses were permitted.
Attributes for the user were searched for, using their IP address, in an LDAP directory.
If attributes were found, the user authenticates as normal and attribute data is shared with the destination eresource
An intercept filter was added to the IdP to halt authentication if no record for that IP address was found in the LDAP directory.
LDAP records were configured using a stand-alone administration interface supplied by DAASI. Any utility capable of updating LDAP could be used, but the DAASI application used in the pilot allows administrators from many different institutions to log in and edit records for their own organisation, so that one service can provide IP-address-based authentication for many
Example User Story
Andy Walker is a journalist and external guest at University One. He does not have an IT account but he does have walk-in access to the University library.
Barbara Jensen is a librarian at University One.
Andy is writing a newspaper article about dogs living on boats, and he visits University One's library to do some research.
He attempts to access a suitable photo archive using a university terminal for walk-in users.
|3.||However, he's blocked - the site requires Shibboleth authentication and he does not have an account.|
He reports this to Barbara at the library support desk and asks for help.
Barbara knows that University One has access to a special IP address-based IdP and that it has access to the archive, so she decides to add the terminal Andy that is using.
Barbara visits the administration page for the IdP, and logs in with her University One credentials.
She adds the IP address of the terminal. (188.8.131.52)
Barbara then asks Andy to try again, and to use the IPA IdP.
|6.||Andy returns to the terminal and tries again - and this time he can log in to the eResource. He is now able to do research for his article.|