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

Compare with Current View Page History

« Previous Version 3 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.  
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

 

DOGS https://sp24-test.garr.it/dogs-101.html

  • No labels