LIN and Shibboleth: Where do application and network access control systems meet?

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

2. Two stones – one bird? • Shibboleth • Currently focused at providing access control for web-based 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/

3. 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?

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

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

6. Building the LIN infrastructure • Each local site could have a RADIUS trust relationship with every other site it wishes to accept guest users for • But this doesn’t scale well to hundreds/thousands of sites • Instead, we can have a national proxy, to which each site ‘peers’ for RADIUS referrals • 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

7. LIN components Local RADIUS server Wireless LAN LIN National RADIUS proxy Home RADIUS server Roaming User 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

8. 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?

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

10. LICHEN project • Funded by JISC in the Core Middleware Programme • Three partners: • University of Southampton • University of Bristol (Josh Howlett) • University of Manchester (Mark O’Leary) • Goal is to explore/show value-add for the LIN • 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

11. 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’

12. The VO perspective • A VO - e.g. a multi-site project - will have • Users and Resources • Any given project will need to define policy for which users can access which 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

13. LICHEN server perspective • Holds policy definitions for one or more VOs • Which users may access which resources • Receives access requests from applications via RADIUS (user ID, resource ID) • 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

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

15. Design and development • Captured some discussion on project web site • http://lichen.bris.ac.uk • 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 • Used FreeRADIUS as the RADIUS platform • Currently testing and soliciting feedback • Also carrying out more detailed security analysis

16. LICHEN implementation • Requires minimal changes to standard FreeRADIUS • LICHEN server performs authorisation • LIN performs authentication • No changes to the LIN required • Developed web-based GUI for policy management • Policy is stored in a database • 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

17. Demonstrators • Demonstrating with various applications: • Web resource: wiki • Remote login and command execution: ssh • Version control system: cvs • Network login system: Windows access (pGina) • Wiki demonstrator online • 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

18. 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 Parallels with Shibboleth?

19. Ongoing tasks • Richer policy definitions on LICHEN server • Scope of this project is ‘basic’ functionality • Security analysis • Depends on the application being ‘LICHENised’ • Important if we have ‘single sign on’ credentials for LIN • Shibboleth relationship • Potential to be complementary? • Interoperability? • Various possibilities, e.g. some from of WAYF shim? • Usability tests • From installation, administration and usage perspectives

20. Birds and stones… • Two good systems emerging in Shibboleth and LIN • Both supported strategically by JISC and UKERNA respectively. Can be complementary. • But could Shibboleth be extended to network admission control? • 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 