You are here

Procedures and Processes Related To AccessNet Provisioning

Scope and Rationale

This document outlines how AccessNet accounts are provisioned (and subsequently deprovisioned).

This document pertains only to the creation of AccessNet accounts.


AccessNet accounts are created when:

  • a person is paid as an employee by or receives benefits from the University;
  • an individual is deemed as an active student requiring an AccessNet account (as defined by either the Student Collaboration Center or Continuing Education);
  • a guest is sponsored by an eligible University employee, and approved by authorized individuals within their school/college/department;
  • a visiting faculty guest is sponsored by an eligible University employee, and approved by the Vice Provost for Faculty Affairs [1] or named delegate;
  • administrative access is required for an application that is not able to perform 2-factor authentication.

The existence of an AccessNet username and password does not automatically grant privileges (Authorization); it merely means that Temple asserts that the given person has logged in (Authentication). Applications are responsible for checking appropriate Authorization before granting access


Authentication - an assertion that a user is who we believe them to be. This generally means that the user has submitted an AccessNet username and password that match our records, but might also include more sophisticated login (such as two-factor).

Authorization - a determination performed by applications as to whether or not a given user should be allowed to use the application and/or see its data. Applications at Temple generally make Authorization decisions based on information in LDAP, such as Roles, Role Attributes, and maximum Level of Assurance; or through group membership in Active Directory.

Level of Assurance - a measure of how sure we are that a login action was performed by a specific person. This is a combination of the maximum level of assurance, which is determined by the way the AccessNet account was provisioned [2] [3] and the security of the mechanism used to authenticate the user [3] (i.e. was the connection cryptographically secure; did the user use two-factor authetication, or just a username and password).

Account Types and Provisioning Flows

There are four distinct types of AccessNet accounts, and three related ancillary types of account.

Students (AccessNet)
The bulk of our accounts are students. The Student Collaboration Center functional lead defines what an "active student" is; the technical lead manages a SQL query which identifies new students - per the functional lead definition - in the University's ERP system.

Employees (AccessNet)
Like the student account flow, the HR Collaboration Center's functional lead defines what an "active employee" is; the technical lead manages a SQL query which identifies new employees in the University's ERP system.

Guests (AccessNet)
The Guest Access Request System (GARS), part of TUPortal, manages requests for guest accounts. Two types of guest accounts exist: normal "NTU" guest accounts, which are run-of-the-mill low assurance and low privilege accounts; and "TVF", which are relatively low privilege Faculty guest accounts (for visiting and volunteer faculty). Requests placed in GARS (by eligible employees) are common-matched against Banner data and then routed to a list of allowed approvers [4].

Continuing Education (AccessNet)
CE accounts are staged directly from the Continuing Education system. These have multiple different levels of access depending on the individual classes.

  • Administrative ("_Admin") supplemental accounts
    A small number of users have administrative alter-ego accounts which are used for administrative functions in applications that do not have a good mechanism for handling internal authorization elevation with multi-factor logins (e.g. TUMarketplace). These accounts (named like "tuz12345 Admin") are manually provisioned by OIAM, and are tied to users' central account (thereby making them expire when their primary AccessNet expires). These accounts do not replicate to AD, and are therefore not available via ADFS.
  • ​Superuser ("su-") supplemental accounts
    Security reviews these requests, and then manually provision the accounts in their systems. Deprovisioning and reconciliation happen periodically through the day, drawing on the Employee Separation script (which feeds off of email from HR, at the time of employee separation notification). None of this is under the control of OIAM.
  • Departmental accounts
    Departmental accounts are managed by the Departmental Account Management app in TUPortal. Requests for a departmental account are approved by Security; this approval triggers automatic account creation as alternate "ou=personae" accounts. This means that departmental accounts are not quite AccessNet accounts; they cannot be used, for example, for Shibboleth federated authentication.

    Note: Departmental accounts should be avoided, as they are shared credentials that can not be definitively tied to a specific end-user.

References and Footnotes


[2] NIST OMB M-04-04 defines four levels of assurance - see

[3] NIST SP 800-63-1 defines guidelines for identity proofing at each of the four levels of assurance - see

[4] The original list of NTU approvers in GARS was built around the signature authority "short list." TVF approvals are performed directly by the
Office of Vice Provost for Faculty Affairs, or their designees (with these delegates spanning the campus, as they deem appropriate).