6/12/2016 AEB/Yleisesittely WLAN roaming experiences using Shibboleth TNC 2004, Rhodes 7th of June, 2004 Mikael Linden, Viljo Viitanen,

6/12/2016 AEB/Yleisesittely Background: AA issues in TERENA Terena TF-Mobility work on roaming access on network level deliverable G: Preliminary selection for inter-NREN roaming –802.1X & RADIUS hierarchy –VPN & complete list of VPN gateways –web redirection & RADIUS hierarchy –ROAMNODE & RADIUS hierarchy Terena TF-AACE work on inter-institutional application level access multitude of AAI technologies being deployed –Shibboleth, PAPI, FEIDE, A-select… In GN2 AA issues to be bridged in JRA5

6/12/2016 AEB/Yleisesittely Background: University of Helsinki (UoH) Largest university in Finland: students (total in Finland) Campus in downtown of Helsinki University of Helsinki deliberate to join WLAN roaming –would not be fair for UoH: probably considerably more visitors coming in than going out?  costs would accumulate for UoH UoH could allow roaming access for some smaller subgroup (e.g. staff in other universities)  authentication not enough, role based authorisation needed role attributes need to be passed from the home institution that’s what AAI technologies are made for

6/12/2016 AEB/Yleisesittely How it works Helsinki university public access network (HUPnet) Access control device (shibboleth target) WAYF Shibboleth origin University of Helsinki University of Tampere (UTa) Bob, a lecturer at UTa SSL Port 443 open to: WAYF: UTa: … ACD redirects user to WAYF 2. User selects his home institution from web form in WAYF 3. UTa Shibboleth origin authenticates the user 4. Shibboleth attribute exchange passes user’s role to ACD 5. Based on the role, ACD grants or denies access to Internet 1. ACD redirects user to WAYF 2. User selects his home institution from web form in WAYF 3. UTa Shibboleth origin authenticates the user 4. Shibboleth attribute exchange passes user’s role to ACD 5. Based on the role, ACD grants or denies access to Internet

6/12/2016 AEB/Yleisesittely Benefits makes role based authorisation easy –visiting institution makes access control decision based on the user’s role provided by the her home institution preserves privacy –user’s identity need not to be revealed to the visiting institution (only her role and home institution is revealed) better security than plain ”web redirection & RADIUS” model –user’s uid and password passed in SSL tunnel between her browser and her home institution’s Shibbolet origin –visiting institution never sees user’s password brings together network and application level access architecture –no need for overlapping architecture

6/12/2016 AEB/Yleisesittely Disadvantages In Europe, cross-organisational and cross-national AAI infrastructure in not so mature as RADIUS based hierarchy –Shibboleth used in Switzerland and Finland, UK starts piloting To allow user enter her uid&pwd to her shibboleth origin site, the access controller needs to maintain exhaustive list of shibboleth origin sites in the federation –new list have to be updated regularly –however, the list have to be maintained by WAYF in any case

6/12/2016 AEB/Yleisesittely Practical experiences: HUPnet HUPnet (Helsinki University Public network) has been available for UoH staff&students since 2001 –for WLAN and wired (ethernet) public access in UoH premises –ACD is a Linux box with web end-user UI UoH has demonstrated shibbolized Access control device (ACD) –previously: AA was based on RADIUS –now: Shibboleth Planned to start piloting between University of Helsinki and other Finnish Shibboleth universities before autumn implementation to be publicly available

6/12/2016 AEB/Yleisesittely Conclusions WLAN roaming based on Shibboleth provides role-based access control to public access network increased privacy WLAN roaming based on Shibboleth requires operational Shibboleth federation maintaining list of home institutions in each access controller WLAN roaming based on Shibboleth could be a way to unify network and application level remote access