Skip to end of metadata
Go to start of metadata

Status: non-normative and possibly out-of-date; content derived from "Netids, They Are A Changin’" from October 2004.

One NetID per User for Life

UW NetID policy states:

You have just one personal UW NetID, no matter how many different associations you have with the UW (e.g., student plus staff plus alumnus/a). Your UW NetID remains the same throughout your life.

Sometimes NetIDs Change

Nonetheless there are circumstances that warrant changing a user’s NetID.  A few such examples are:

  • change of legal name
  • obviously inappropriate choice by user who didn’t realize NetID would be “visible”
  • extreme need for “privacy” after email harassment

In the past year, the rate of NetID changes has been as high as 50 changes/month, where ‘50’ represents about 1% of the active user population.

The Trouble with Changing NetIDs

NetID changes are highly discouraged.  They incur overhead on the part of the Help Desk, application administrators, and the user.  Often, they result in service disruptions to the user.  Help Desk only manages the NetID change for a few core services.  Generally, the user must himself contact administrators of other applications that use the NetID or pubcookie authentication for recognition or access.  The user may not be aware of all the applications affected by his NetID change; thus, several weeks after the change, he may have difficulty accessing a service and not know why.  This sort of confusion may lead to a Help Desk call, amplifying again the support overhead associated with a NetID change.

The Unaware Application

Applications that assume a user’s NetID will never change increase the likelihood that a change will be cumbersome and costly to handle.  An application unprepared for NetID changes may:

  • encourage the user to keep using the old NetID
    • the user must remember both old and new NetIDs, which is confusing and reflects poorly on UW computing systems
    • if pubcookie authentication is used, it will eventually stop working for the old NetID, resulting in a service disruption
  • require the user to contact the app administrator to make the change, which is not very user-friendly
  • require the administrator to make manual updates to one or more data tables, which is not very admin-friendly and may be error-prone

Application Development Team Choices

It’s a fact of life.  Applications must handle NetID changes.  In the ideal world, a user would be able to login to all UW applications with his new NetID shortly after a change, and without making extra phone calls.  Application developers can help make this happen by designing or acquiring software with an awareness of NetID changes.  Emphasis should be placed on improving business processes by:

  • optimizing the user experience, and
  • reducing Help Desk/administrative overhead,

rather than on application ease of development.

To prepare for NetID changes, application teams should, at a minimum:

  • establish a procedure for handling NetID changes in the application, and
  • test this procedure as a part of deployment testing.

Application Design Tips

  • Minimize NetID dependencies
    • Don’t use the NetID to cross-index multiple data tables.  A NetID change would then require updates in several places. 
    • Don’t use NetID as the sole key to a person’s records.  This makes it harder to locate records, especially programmatically, when the old NetID is forgotten or its pubcookie authentication is disabled.
  • Anticipate NetID changes with nightly reports
    • Nightly reports of NetID changes will be available soon (Spring ’03, with Person Registry Nantucket release) via subscriber email or web posting.  Send your notification type preference or questions to
    • Alert app administrators to contact users and coordinate NetID update, or
    • Automatically update stored NetIDs and alert user of the change
  • Use uwRegID instead of NetID
    • A person’s RegID never changes, though their name, NetID, and affiliations may change.
    • A RegID query on the Person Registry returns a person’s affiliations and system IDs for other sources (like HEPPS, SDB, …)
  • Use RegID in addition to NetID
    • NetID provides an efficient internal lookup for apps using pubcookie authentication
    • If NetID internal lookup fails (aha!  perhaps the user logged on with a new NetID), query Person Registry for RegID and use that for internal lookup.
    • Map the old or new NetID to the RegID with a call to Person Registry.
  • Make sure user is NOT LOGGED IN when internal NetIDs are updated to avoid access problems during the session

Evaluating Third Party Software

When evaluating third party software for integration with UW systems, consider:

  • Flexible person ID fields
    • They should be large enough to handle the 128-bit RegID, which is an unchanging reference to UW person data in other sources.
    • If NetIDs are stored, the ID field must accommodate changes without disrupting service.
  • ID Mapping Layer
    • If RegIDs can’t be stored internally, the software should support a layer that maps internal IDs to RegIDs.
  • Increased support costs for NetID changes
    • Extra support costs due to inflexible software should be part of the purchase decision.
  • No labels