==== DRAFT / WIP ==== 

...

Super Walk-In Users Portal -

...

Library Pilot Scenarios 2 & 3

Introduction

Two major obstacles preventing University Reliance on using IP addresses to authenticate users prevents some university libraries from moving to all-fully 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.

to online resources. Despite the many disadvantages of controlling access using IP addresses, they are relatively simple to set up at a small scale, and can be useful in two contexts: accessing out-dated eresources that do not support modern authentication (which has been explored by AARC here) and providing access to "walk-in" users.

Kiosks for Walk-In Users

Many libraries use IP-address 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. . Walk-in users may be alumni, local residents, employees of companies working with the library or children at local schools. It may be too slow or costly to manage IT accounts for these users.

Walk-in users visiting a library can be given access to eresources by using "kiosk" terminals - PCs that have been locked-down to be secure enough for anonymous use. Kiosks will limit the software and websites that can be accessed, and provide a friendly menu of available resources.

Eresources will normally grant access to these terminals by relying on IP address authentication.  

Problems with the IP address Kiosk approach

(DIAGRAM)

: each kiosk will have a static public IP address or be in a range of network addresses known to be used by walk-in users.

Problems With A Purely IP-Address Kiosk

Dependency on legacy technology: In order to support walk-in users all accessible eresources must continue to provide IP-address authentication. This discourages them from properly modernising and federating access to their service.

Scalability: All Requires all eresources (potentially a large number) to must be configured with the IP addresses of all kiosks. Adding a new kiosk will be awkward and time-consuming and require changes at many different websites. In some cases changes must be requested by email.

Security and licensing risks: De-provisioning or updating 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

Possible Solution: Managing accounts for Walk-In Users

If a library provides accounts for walk-in users they can log in normally, using the same IdP as staff and students, and access federated resources and IP-authenticated resources via EZProxy.

Unfortunately this is often impractical for the potentially large number of casual, occasional walk-in users that could potentially visit a library.

Possible Solution: IP Address Authentication at the library IdP

A SAML IdP (such as the Shibboleth IdP) The Shibboleth IdP can be configured to automatically authentication authenticate users logging in from defined ip 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:
Not all libraries have available SAML IdPs. 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

, and the IdP may be managed by a different department. This can lead to delays and deprovisioning risks, and leave library staff feeling frustrated.

Implemented Pilot Solution: A shared, easily configured IdP service for Walk-In users

This pilot demonstrated the use of a dedicated, IP-address based IdP. The pilot service has some distinctive features:

* It is for use only by walk-in users
* It is authenticated only by IP addresses
* It is managed by library staff via a web-based admin interface
* Library staff access the administration interface using their own institutional credentials
* Changes to the configuration for access control are available immediately.
* The IdP can can be run for one organisation or for many, as a shared service. It can be shared by a group of institutions in the same region, or even at a national federation level.

Authentication and User Attributes

The pilot service will not allow authentication from IP addresses that are not listed in its admin UI.

All authenticated users are given a walk-in-user affiliation.

Every IP address or network address range can be configured to share arbitrary entitlement information.

IP addresses can be assigned different domain scopes, determined by the scope of the administrator who configured the ip address range. This allows SPs access using the service to differentiate between users at different libraries.

How the Pilot Service Was Configured

A standard Shibboleth IdP v3 was used.

Authentication was configured to only use IP addresses , and all using the default network address authentication module that is included in the Shibboleth IdP. All IP addresses were permitted by default.

An IdP extension was used to collect the user's IP address. This can also be done using Javascript within the IdP, if Shibboleth IdP v3 is used.

Attributes for the user were searched for , (using a numeric version of their IP address, ) in an LDAP directory. Records in the LDAP directory contain normal user attributes but records are for network address ranges, not users.

If attributes were a matching LDAP record with suitable attributes is found, the user authenticates as normal and attribute data is shared with the destination eresource.

By default all IP address ranges can authenticate, so the LDAP attribute information (or lack of it) is used to provide a second authentication step. An intercept filter was added to the IdP to halt authentication if no record for that IP address was 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 

many

Practical Implications

The IdP can be used by many different organisations as a shared service, and can use a variety of scopes, but it cannot be used to access existing eresource SPs without additional configuration at the SP, and additional licensing agreements.

Scopes must be configured in the SPs metadata to be accepted: basic security checks in most SPs prevent IdPs from using arbitrary scopes.

Most academic eresources are configured to permit access according to licence agreements by matching the licensee's entity ID to supplied attribute data. As the shared IdP in the pilot has a new entity ID that is potentially shared by many organisations, each SP must configure access for each user of the shared IdP by checking against both scope and entity ID. 

Demonstration

Example User Story

...