Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

 

==== 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.


This is a user story featuring two users at a university called Typical University One.

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.

 
2.

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.

https://saml-eresource.libs3.aarc.demo.university/

3.However, he's blocked - the site requires Shibboleth authentication and he does not have an account.
4.

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.

https://adminportal.lib.pilots.aarc-project.eu/lui/ldapportal.pl

5.

She adds the IP address of the terminal. (82.69.55.233)

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.

 

  • No labels