==== DRAFT / WIP ====
DEMO for the Super Walk-In Users Portal - LIbrary Pilot # 1 - Scenario 3
Introduction
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
(DIAGRAM)
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.
An IdP extension was used to collect the user's IP address. This can also be done using Javascript within the IdP if Shibboleth v3 is used.
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
Demonstration
Example User Story
| 1. | ||
| 2. | ||
| 3. | ||
| 4. | ||
| 5. | ||
| 6. | ||
| 7. |
| |
| 8. | ||
| 9. | ||
| 10. | ||
| 11. | ||
| 12. | ||
| 13. |
| |
| 14. |
| |
| 15. |
|
For non-federated users
Components
Benefits
Demo Video
https://drive.google.com/open?id=0B6nLU4k7ZZvfUjNhNHdKYkNHTmc
Transcript https://drive.google.com/open?id=0B6nLU4k7ZZvfU3lNalN2Q2JsYzA