UCTrust Wireless Notes - 2010-06-22

UCTrust Wireless Agenda - 2010-06-22

• Slides used during the meeting: UCTrustWireless-2010-06-22.ppt 

Participants

Project Scope

The consensus was that this specific project is a pilot project to federate authentication to the wireless networks at the sixparticipating campuses through the use of UCTrust.  The ultimate goal, however, is to extend this solution to the rest of UC, as well as to other universities within InCommon, so we will pay attention to the broader issues involved with this ultimate goal as we implement at the initial six campuses.

During the discussion, the question was raised if UC should have a common SSID for guest wireless access. The consensus was that we should not pursue this.

The original charge from the ITLC in February said that we should have something working by Fall, 2010.  Since this group was not created until May, we will need to adjust expectations.

Identity Attributes

At a minimum, an indication that a guest is a member of another UC campus community is required to authorize guest access to a wireless network.  Most campuses also want name and electronic mail address, in case they need to contact the guest.

We believe the "Member" affiliation is appropriate to authorize guest wireless access, but we will explore the issue more in our next call.  "Member" affiliation is defined to include students, staff, and faculty, plus other groups that a campus may designate, so we agreed to added a column to Existing Campus Wireless Authentication where each campus will say if it can assert "Member" and, if so, how the attribute is defined.  It appears tha more than one campus does not currently implement "Member."

[Post meeting note:  The eduPerson Object Class Specification states: " 'Member' is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., they are given institutional email and calendar accounts). It could be glossed as 'member in good standing of the university community.' "]

Access to Guest's Campus's Identity Provider (IdP)

Because Shibboleth requires access to a user's home institution's IdP, unauthenticated wireless access on participating campuses will need to have those IP addresses open.  This means that we will need a mechanism for discovering or distributing those IP addresses.  It was suggested that the InCommon metadata may have sufficient information to do this.

Next Steps and Next Meeting

• Finalize our discussion of identity attributes.
  • Homework for the next call
    • Everyone should complete the new column in Existing Campus Wireless Authentication.
    • Consider whether "Member" affiliation will be sufficient to grant guest wireless access.
    • Consider whether guest wireless access should be granted if, for some reason, a Shibboleth assertion is received without name and/or email address.
• Resolve how we discover / distribute IP addresses that must be accessible without authentication.
  • Homework for the next call
    • Determine if the InCommon metadata contains enough information to identify the IP addresses that must be open in order to authenticate to your campus IdP.
• We will schedule another call in approximately two weeks.