SFU User Interface Access Model

Owned by Jeremy Jeremy
Last updated: Aug 12, 2009Version comment
2 min read

At SFU access to our Account Maintenance (Amaint) system has grown to accommodate business users as required. The following main access levels have evolved:

L1: Read Only - General Help Desk operators
  • Calculated Person information (less birthdate)
  • SoR specific information (department for staff, courses for student)
  • Computing Account information (status, activation date, Display Name, UID)
  • Email Aliases
  • Unix home directory path and quota
  • Public email directory information
  • History logs
L2: Account Clerk - General administrative staff in the computing services office
  • All L1 access
  • Maillist membership (analogous to Grouper membership but in homegrown system)
  • Reset Password
  • Manual Activation (we have an automated activation system but when users are unable to use it, they must present ID and have the account manually activated)
L3: Account Admins - Senior Administrators and IT Directors
  • All L2 access
  • Create Guest accounts
  • Manage Department Name Mapping
  • Lock Accounts
  • Disable Accounts
  • Add new Email Aliases
L4: System Admins - Developers
  • All L3 Access
  • See birthdate
  • Push Maillist membership to an AD group
  • Setup static email aliases
  • GUI into select database tables
  • Manually Trigger import of HR and Registrar Files
  • Start/Stop message queue to SoRs (HR/Registrar)
  • Manually push individual messages to SoRs (HR/Registrar)
Special cases and exceptions
  • Defined group of L1 AD admins can push Maillist membership to an AD group
  • Defined group of L1 PeopleSoft admins can start/stop message queue and push individual SoR messages
  • Birthdates are viewable by select senior L1 and L2 operators and clerks (birthdates are required for account activations so one senior person on duty must be able to see and verify birthdates)
Summary

This is not a perfect system, some of the access levels were somewhat knee jerk reactions to problems that should have been handled administratively, not technically. Specifically the handling of birthdates. When staff and faculty birthdates were added to Amaint, there was some abuse of this information at the L2 level and so the ability to see birthdates was locked down. Birthdates should be visible to L1 with appropriate discipline in place when privacy is breached by users. Similar issues came up around email aliases, certain unprofessional aliases were denied by L2 staff in one office and then allowed by different L2 staff in a different office so alias creation was locked down as well. These are policy issues that need to be addressed through people management.