Draft UC Berkeley Guest Account Requirements:

Last updated January 23, 2011

General Guest Account Requirements

  • Guest accounts will be generic and not confer any specific service access privileges
  • Each service owner who wishes to grant access to guests will establish specific authorization requirements for that service (see below for requirements parameters)
  • All service authorizations shall include an expiration date that varies from a minimum of 1 day to a maximum of one (i.e. renewal will be required at least once per year)
  • Guest accounts will be divided into two categories: short-term (1 day to 1 month) and long-term (1 month - 1 year)
  • All guest accounts will expire one year after all service authorizations have expired (guests will receive an email at their address of record 3 weeks and 1 week prior to account expiration)
  • All guest access will require sponsorship
  • Guest accounts will be housed in a separate LDAP container (e.g. ou=guest people), similar to the way we currently handle alumni accounts
  • We will not have an expired container for guests. One year after all service authorizations have expired, the account will be deleted.
  • Creation and modification of guest accounts should be logged.
  • The guest account system should support the creation of guest accounts by administrators either singly or in bulk and via Oracle Waveset interfaces or via departmental apps (sent to Oracle Waveset over SPML)

Short-term Guest Accounts

  • Planned uses: campus wireless access, VPN, online content sharing tools (SharePoint, Alfresco, conference guests)
  • Level of assurance: none
  • Duration: Maximum one month
  • UserName: Short-term guests will be assigned a user name with the format "guest-XXXX"
  • Provisioning: Account requested by user or sponsor, approved by sponsor, and provisioned to key campus IdM stores (Oracle Waveset, Kerberos, LDAP, AD) via Oracle Waveset
  • *Please note: Many campus departments would prefer a method to allow transient users to authenticate with an existing open identifier (OpenID, Facebook, Google, etc).

Long-term Guest Accounts

  • Planned uses: guest lecturers, Course Management system (Sakai), contractors, online content sharing tools (SharePoint, etc.)
  • Level of assurance: Tiered. Managers of systems on campus can require that guests undergo face-to-face identity vetting (ultimately InCommon Silver level) assurance.
  • Duration: 1 month - 1 year (auto expiration after one year with option for renewal)
  • UserName: Long-term guests will establish a "CalNetID" at the start of the their first authorization. If these guests ever become regular staff or students, they can continue to use this identifier and will not lose existing authorizations in campus systems.
  • Departmental admins should be able to convert staff/student accounts into guest accounts when people move off payroll but need to maintain existing service authorizations.
  • Provisioning: Account requested by user or sponsor, approved by sponsor and/or administrator, and provisioned to key campus IdM stores (Oracle Waveset, Kerberos, LDAP, AD) via Oracle Waveset
  • No labels