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