Transcript WLAN roaming experiences using Shibboleth

AEB/Yleisesittely
7/15/2015
WLAN roaming experiences using Shibboleth
TNC 2004, Rhodes
7th of June, 2004
Mikael Linden, [email protected]
Viljo Viitanen, [email protected]
AEB/Yleisesittely
7/15/2015
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
AEB/Yleisesittely
7/15/2015
Background: University of Helsinki (UoH)
• Largest university in Finland: 38 000 students (total 170 000 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
AEB/Yleisesittely
7/15/2015
How it works
SSL Port 443 open to:
WAYF: 193.166.0.69
UTa: 153.1.6.41
…
WAYF
193.166.0.69
2.
3.
Access control
device
(shibboleth target)
1.
Helsinki
university public
access network
(HUPnet)
Bob,
a lecturer at UTa
University of Helsinki
4.
University of
Tampere (UTa)
Shibboleth origin
153.1.6.41
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
AEB/Yleisesittely
7/15/2015
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
AEB/Yleisesittely
7/15/2015
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
AEB/Yleisesittely
7/15/2015
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
• http://www.helsinki.fi/atk/english/network/HUPnet.html
AEB/Yleisesittely
7/15/2015
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