LIN and Shibboleth: Where do
application and network
access control systems meet?
Tim Chown
tjc@ecs.soton.ac.uk
University of Southampton (UK)
JISC Core Middleware Programme
Security and Access Management Workshop
Edinburgh, 20th October 2005
Two stones – one bird?

Shibboleth




Currently focused at providing access control for webbased systems, at application layer
Main focus of JISC Core Middleware Programme
Strategic push by the JISC for service in 2007 onwards
Location Independent Networking (LIN)



Enabling inter-campus roaming for Wireless LAN users, i.e.
a standardised means for network layer access control
30 site pilot completed, service specifications drawn up
UKERNA pushing to service in first half of 2006
 See http://www.ja.net/development/aa/lin/
From the LIN perspective…

In this talk we’ll look at the LIN view




The network layer authorisation and authentication
The LIN pilot, and associated authentication infrastructure
The scalability of the system
And where LIN might be extended


How this could be made available to the application layer,
as demonstrated by the Location Independent
Collaboration in Higher Education (LICHEN) project
 See http://lichen.bristol.ac.uk
If the LIN infrastructure exists, will sites be tempted to use
it for authentication duties beyond Wireless LAN?
Wireless LAN origins

LIN found that there are two scalable solutions for
roaming support in WLAN access control systems



Web-redirection based access control - user cannot access
external networks until they enter credentials on their first
attempt at web access
802.1x access control - access to the layer 2 network (port)
not granted until user enters their credentials
In both cases, credentials can be passed from the
access control device by the RADIUS protocol to an
authentication back-end service

RADIUS is a long-established standard protocol, designed
to carry authentication requests
Properties of RADIUS

RADIUS …




…is agnostic to the authentication back-end
…carries access requests and replies
…supports proxying between RADIUS servers
At a site’s WLAN hotspot, the local site’s RADIUS
server is passed the user’s credentials by the
access control device



Local users are then authenticated locally
Remote user credentials are forwarded to their home
RADIUS server (i.e. authenticated by the home institution)
WLAN access is granted if the authentication is successful
Building the LIN infrastructure

Each local site could have a RADIUS trust
relationship with every other site it wishes to accept
guest users for


Instead, we can have a national proxy, to which
each site ‘peers’ for RADIUS referrals



But this doesn’t scale well to hundreds/thousands of sites
The national proxy is operated by UKERNA
And you can run multiple proxies for resilience
This model implies an ‘all-trust-all’ relationship

But the existing LIN participants seem happy with that
LIN components
Local RADIUS
server
Wireless LAN
Roaming
User
LIN National
RADIUS proxy
Roaming user authenticates
to WLAN via 802.1x or web-redirection
system to local RADIUS server, which
refers non-local credentials via National
RADIUS proxy to user’s home site
Home RADIUS
server
Building on the LIN

The Location Independent Networking (LIN) pilot
currently spans around 30 universities





Enables WLAN device roaming between participant
institutions – users from any site can get access anywhere
Relies on RADIUS ‘web of trust’
Simple to deploy (most sites use RADIUS already)
First trials have gone well - all sites are continuing to
service launch in first half of 2006
Has strong potential for growing roaming community

What else can we do with this infrastructure?
Cue LICHEN…

LICHEN is a project that builds upon previous
JISC and UKERNA work


Mobile Ad-hoc Wireless Access in Academia
(MAWAA), which studied WLAN access control
methods, and how these could support inter-site
roaming by users
Location Independent Networking (LIN),
operational both nationally and internationally,
working with TERENA TF-Mobility and eduroam


See http://www.eduroam.org
Exploring if or how far we can extend the LIN
LICHEN project


Funded by JISC in the Core Middleware Programme
Three partners:




Goal is to explore/show value-add for the LIN


University of Southampton
University of Bristol (Josh Howlett)
University of Manchester (Mark O’Leary)
We feel that sites will probably use LIN for added value in
time anyway, so it is important to ‘pathfind’ for them
Now in the last quarter of the project

Project timeline: Nov’04 to end of 2005
Application support

Many applications have hooks to RADIUS






Apache htaccess files
Version control (cvs)
SQL databases
PAM
imap, etc…
We wish to adapt the LIN infrastructure to support
Virtual Organisations (VOs) that wish to use such
applications

But many applications may be web-based, e.g. wikis, and
these could also of course be ‘Shibbolised’
The VO perspective

A VO - e.g. a multi-site project - will have


Any given project will need to define policy for which
users can access which resources



Users and Resources
Users: e.g. user@homeuni.ac.uk
Resources: a resource ID to identify each application
Introduce a LICHEN RADIUS server



Defines these policies on a single system for the VO
Application uses RADIUS interface to LICHEN server
Home institution’s RADIUS server does not need to know
its users’ VO memberships
LICHEN server perspective

Holds policy definitions for one or more VOs


Receives access requests from applications via
RADIUS (user ID, resource ID)



Which users may access which resources
If policy says user may access the resource, LICHEN
server passes user credentials to the LIN hierarchy for
authentication
A positive response from the user’s home RADIUS server
confirms authorisation, which the LICHEN server returns to
the application
Thus a user has the same credentials for WLAN and
VO use; a strength and a potential weakness
LICHEN model
VO LICHEN
RADIUS server
Application
LIN National
RADIUS proxy
Home RADIUS
server
VO user
VO user’s application refers authorisation
to VO LICHEN RADIUS server, which - if
Policy is met - refers user credentials via
National RADIUS proxy for authentication
Design and development

Captured some discussion on project web site


Made an early survey of collaborative projects




Surprisingly small set of applications used
Newer ‘trendy’ tools, e.g. wiki (the LICHEN project web site
uses a version called twiki)
Determined some applications to ‘LICHENise’
Designed and built LICHEN servers


http://lichen.bris.ac.uk
Used FreeRADIUS as the RADIUS platform
Currently testing and soliciting feedback

Also carrying out more detailed security analysis
LICHEN implementation

Requires minimal changes to standard FreeRADIUS





Developed web-based GUI for policy management
Policy is stored in a database


LICHEN server performs authorisation
LIN performs authentication
No changes to the LIN required
Offers independence from RADIUS implementation, and
also to avoid needing to ‘HUP’ server when changes occur
(which is often required with plain text configuration files)
On web server side

Apache with mod_auth_radius
Demonstrators

Demonstrating with various applications:





Wiki demonstrator online



Web resource: wiki
Remote login and command execution: ssh
Version control system: cvs
Network login system: Windows access (pGina)
Controls editorial access to LICHEN project site
Interest also from UKERNA WAG, SWERN, others
pGINA login demonstrated at Networkshop 2005

Tested and deployed by Manchester
Parallels with Shibboleth?

Shibboleth model








‘Complex’ deployment (HS,
AA, etc…)
Web-based applications
Allows user privacy (designed
in from outset)
Uses own infrastructure to
carry credentials
WAYF service locates home
authenticator
Secure channel to
authentication server via
redirect through WAYF
Strong attribute model
Getting some traction, and
strong steer from JISC

LICHEN model








Simpler deployment
Wide range of applications
Visited site sees credentials
Uses existing RADIUS-based
authentication infrastructure
(LIN)
LIN RADIUS proxy locates
authentication server
Needs TLS-IA extension to
offer credential security (and
potentially privacy)
Attribute models ‘lacking’
LIN pilot by UKERNA going to
service in 2006, successfully
used at Networkshop 2005
Ongoing tasks

Richer policy definitions on LICHEN server


Security analysis



Depends on the application being ‘LICHENised’
Important if we have ‘single sign on’ credentials for LIN
Shibboleth relationship



Scope of this project is ‘basic’ functionality
Potential to be complementary?
Interoperability?
 Various possibilities, e.g. some from of WAYF shim?
Usability tests

From installation, administration and usage perspectives
Birds and stones…

Two good systems emerging in Shibboleth and LIN


But could Shibboleth be extended to network
admission control?



Both supported strategically by JISC and UKERNA
respectively. Can be complementary.
And if it can, should it? If so, how?
If not, are there ways to ‘harmonise’ Shibboleth and LIN?
Is LICHEN a viable authorisation model for small
group collaboration?

It can be… but if it shouldn’t be, why not? Discuss 