Guest Users for Wireless Access: A Prototype

By Erick Engelke
Engineering Computing
Last Updated August 18, 2009

Wifi networks were originally not allowed on campus because we did not have a method to authenticate users.  This requirement was later satisfied with the introduction of the Network Authentication Appliance (NAA).  More recently we have moved to authentication as part of our Aruba wireless deployment.

Authentication has allowed us to track many computer issues to a particular userid.  We contact users of virus laden computers or when there is illegal or improper user activity.  Quite simply, mapping computers to userids is necessary to manage our wireless environment effectively. 

Authentication also has a downside, it prevents logins from campus guests who lack UWuserids.

We have many guests:

- Conference attendees

- Visiting scholars

- Consultants

- Vendor staff (installation and repairs)

- etc.

Many of them have a legitimate need to use our wireless.  Currently, the only way of getting a guest account is to create an account in ADS or Nexus, and these accounts can only be created by certain IT people with the necessary privileges.  Often our users tell their guests their own passwords so they can authenticate for their visit.

The GuestUser system is a prototype which can eliminate the guest problem by allowing any UW faculty, staff or student the means to vouch for a guest and immediately grant them a temporary userid. 

In the prototype, the guest is granted 30 days of access.  One month is usually sufficient time for most temporary business.  Someone requiring longer access really should have a permanent campus UWuserid

A UW user interfaces with GuestUser through a simple web form.  There, the UW user supplies his UWuserid and password, and the guest’s Email address and preferred password, the system automatically generates and registers a temporary userid, a numbered account like guest345 with the desired password.

GuestUser keeps a database record of each guest:

- The temporary userid

- That userid’s password

- The sponsoring UWuserid

- The guest’s Email address

- The expiry date of the guest account

The database is retained for future use, such as when inappropriate use or viruses are discovered and tracked to the computer logged in with a guest userid. 

GuestUser fits into the authentication stack.  Users can authenticate agains ADS, Nexus, the GuestUser database, or (someday) Shibbolith.  The following slide (mostly created by Mike Patterson) shows how GuestUser fits into the system.

Once the user is authenticated, he is presented with the same minuwet challenge as other users, and can be granted full network access upon passing minuwet.

GuestUser is currently a prototype and can be modified to better fit the campus needs.