You are here

Procedures and Processes Related To AccessNet Provisioning

Effective Dates and Issuing Authority

Effective Date: January 7, 2020
Date Last Reviewed: January 7, 2020
Issuing Authority: Information Technology Services

Scope of Procedure and Rationale

AccessNet accounts are provisioned (and subsequently deprovisioned) to allow for proper access to technology resources available at the university.


AccessNet accounts are created when:

  • A Collaboration Center or other authorized System of Record deems a person as entitled to an account;
  • A guest is sponsored by an eligible University employee, and approved by authorized individuals within their school/college/department;
  • A visiting or volunteer faculty guest is sponsored by an eligible University employee, and approved by the Vice Provost for Faculty Affairs [1] or named delegate;
  • Secondary administrative access is required, where the primary account has insufficient security for the related actions.

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

Account Types and Provisioning Flows

The Collaboration Centers and the other authorized sources sponsor “people” accounts with a variety of roles. There are also related ancillary types of accounts.

Student (AccessNet)
Student Collaboration Center defines and sponsors “Active Student” and other student statuses. 

Employee (AccessNet)
The HR Collaboration Center defines and sponsors accounts with "employee", “faculty”, “staff” and other job and employment related roles.  Each Hiring manager is responsible for keeping employees current in the Banner system.   

Alumni (AccessNet)
The Advancement Collaboration Center owns the definition and access provided to “active alumni”.

Guests (AccessNet)
The Guest Access Request System (GARS), part of TUPortal, manages requests for guest accounts. There are a few types of guest accounts: "NTU" guest accounts, which are run-of-the-mill low assurance and low privilege accounts; "TVF" & “TVF2”, which are relatively low privilege Faculty guest accounts (for visiting and volunteer faculty), “TUR”, which are accounts sponsored by TU Rome, and TUH, sponsored by TU Hospital. Requests placed in GARS (by eligible employees) are common-matched against Banner data and then routed to a list of allowed approvers.

Continuing Education (AccessNet)
Accounts with the “CE” role are staged directly from the Continuing Education system. 

TU Japan (AccessNet)
Accounts sponsored by Temple Japan’s HR system, asserting the “TUJ” role.

Applicants/Prospects (AccessNet)
Accounts sponsored by the Admissions Office, asserting the “Applicant” or “Prospect” roles. These are low-assurance accounts, which do not include TU sponsored email addresses.

Stopout (AccessNet)
Sponsored by the Bursar’s office, accounts with the “Stopout” role are created for a limited 6 month period to allow former students to retrieve their transcripts. The accounts are low-assurance and do not include entitlement to TU email addresses.

Ancillary Accounts: 

  • Administrative ("_Admin") supplemental accounts
    A small number of users have administrative alter-ego accounts which are used to separate their regular account from the elevated access of these administrative functions (particularly for applications that can’t handle multi-factor authentication on the primary account, such as TUMarketplace). These accounts (named like "tuz12345 Admin") are manually provisioned by OIAM and Information Security, and are tied to the users' primary account (thereby making them expire when their primary AccessNet expires). 
  • Superuser ("su-") supplemental accounts
    The Information Security team reviews these requests and manually provisions the accounts in AD.  An OIAM automated process incorporates the accounts in a registry and adds them to LDAP. Account locking or extensions happen automatically through password updates or periodically through the day, drawing on the Employee Separation script (which feeds off of email from HR, at the time of employee separation notification). 
  • Departmental accounts
    The Departmental Account Management app in TUPortal manages these accounts. 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 are intended to function as accounts for departmental email or shared calendar resources only.
  • Miscellaneous accounts
    Used for testing, communication between services, and other one-off functionality.  OIAM maintains a registry of these accounts and is continuously trying to document and possibly streamline those different use-cases. Provisioning of these accounts is done on a case-by case basis. These typically have a one-year manual renewal process (where OIAM contacts owners to see if the account is still necessary).


  • 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 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 and the security of the mechanism used to authenticate the user (i.e. was the connection cryptographically secure; did the user use two-factor authentication, or just a username and password).