1601 PR.01 Access to Oracle Financial and Human Resources Applications

Revision Date: 
January 27, 2009

1 – Overview of User Access at Yale

Restricted Applications
Value-Based Security
Access to Functions
Oracle Responsibilities
Access to Data
Eligibility for Access
Access Must Reflect Current Business Needs
User Access Roles and Responsibilities

2 – Determine What Access a User Requires

Identify Applications, Functions and Data Needed

3 –Request Training and Access

Submit Request
Notification

4 – Approval Process and Guidelines

Approval Process
TAC/Process Owner Approval Steps
Guidelines for Approvers

5 – Monitor Employee Access and Request Modification When Appropriate

Review User Access Profiles
Monitor Employee Status and Duties
Request New or Changed Access
Use User Access Profile to Request Changes
Receive Notification of Change

1 – Overview of User Access at Yale

Restricted Applications

A number of Yale business applications have restricted access in order to guarantee security of sensitive and confidential data and data networks. It is important to ensure that users have access only to the areas required to perform their functions at the University.

This document describes procedures for requesting, modifying and deleting user access to Oracle financial and human resources applications.

Value-Based Security

Value-based security controls a user’s ability to view and/or update information based on one or more attributes designated in the user access request. These attributes can include the:

  • individual’s employment status
  • organization
  • organization level for which access is required
  • individual’s job category
  • individual’s position

The appropriate use of value-based security to restrict user access helps ensure that users can perform their necessary tasks without compromising the privacy of sensitive data.

Access to Functions

Access can be restricted to specific functions within some applications. For example, a user may be given access to the preparer function within Web Requisitions, but not to the approverfunction.

In addition, a user may be given one of the following levels of access to some applications:

  • update (read/write) access: the ability to enter and update data and submit transactions

or

  • lookup (read-only) access: the ability only to view information without being able to enter or change data.

Oracle Responsibilities

Standard access levels have been defined for each Oracle financial and human resources application. These standard levels are known as responsibilities. Responsibilities define which menu items and Oracle forms a user can access, and whether the access is read-only or read/write.

Example:

  • The Human Resources application has defined 19 different responsibilities, such as Dept Lookups Without Salaries, Payroll Enter and Authorize, Benefits, etc. An individual is given access to the Human Resources application for one or more of these responsibilities.

Access to Data

A user’s access may be restricted to specific sets of data within an application.

In most cases it is appropriate for central business office managers and process owners to have unrestricted access to data within their application.

For departmental users, access controls have been implemented for applications where confidential salary information is stored (Human Resources, Labor Distribution), or where, without such controls, end users would be presented with extraneous University-wide data rather than the data that is appropriate to their business needs (Journal Staging Area, VIP, Data Warehouse, Oracle Financial Analyzer).

Examples:

  • Employee A needs access to data only for a specific leaf-level organization within a larger department. But Employee B needs access at the department level, i.e., to all leaf-level organizations within the department.
  • Employee C should have access to Human Resources data only for individuals in the CAS (casual) job category. But Employee D needs access to faculty and C&T and M&P staff data.

The Yale Authorization Subsystem (YAS) uses value-based security to set access controls for each user. The controls are determined from information provided in the user access request. When access is set up, the individual user netID and associated access values are stored in tables referred to as YAS domains.

The table below shows the YAS domains that have been established to meet current business needs and security concerns. Additional domains may be established in the future.

  • For some applications, YAS controls have not been necessary. These include Web Requisitions, for which approvers are defined in the Human Resources system, and Receipt Identification Form (RIF), which automatically limits user access to the transactions that the user has submitted.

YAS domain

Controls access to…

How it works….

Access Organizations

JSA

VIP

Data Warehouse (non-HR/LD)

  • Stores user netIDs and the organizations to which each netID will have access for JSA, VIP and Data Warehouse.
  • Defines access so users view only the data that pertains to their organizations. Users typically need access to the same organization or set of organizations for JSA, VIP and Data Warehouse. Therefore, these applications share the same YAS domain.
  • When a departmental user logs on to one of these applications, YAS checks the user’s YAS Access Organizations value(s) to determine the organization(s) for which the user can create or authorize JSA batches, create and maintain VIP accounts, and view Warehouse data.

Confidential Organizations

and

Confidential Job Categories

and

Stucas Mgr  and Acct Organizations

and

Casual Time Entry and Approval Organizations

HR

LD

  • Because Human Resources and Labor Distribution contain confidential salary information, user access may need to be restricted to a more limited or different set of organizations from those allowed for JSA, VIP or non-HR Data Warehouse reporting. In addition, access may also need to be limited by employee job category. Therefore, access to HR and LD is defined by these two separate domains
  • Confidential Organizations stores user netIDs and the organizations to which each netID will have access for Human Resources, Labor Distribution, and Data Warehouse HR/LD data. This domain works in conjunction with Confidential Job Categories.
  • The Confidential Job Categories domain stores user netIDs and the job categories to which each netID will have access for Human Resources, Labor Distribution, and Data Warehouse HR/LD data. This domain works in conjunction with Confidential Organizations.
  • When a departmental user logs on to HR or LD or to the Data Warehouse, and attempts to locate an employee record, YAS validation checks the user’s YAS Confidential Organizations and Confidential Job Categories values. If the user’s YAS values match the employee’s organization and job category, the user will be able to view the employee data. If not, the user will not be able to see the record.

Budget Organizations

OFA

  • Stores user netIDs and the organizations to which each netID will have access for Oracle Financial Analyzer budgeting and management functions.
  • As in the case of the Access Organizations domain described above, when a user logs on to OFA, YAS checks the user’s YAS Budget Organizations value(s) to determine the organization(s) for which the user can view OFA data or perform OFA functions.

 

Eligibility for Access

Individuals (faculty, staff, student, or other) may obtain access if appropriate approvals are obtained (see 4 – Approval Process and Guidelines). For access to most Oracle financial and human resources applications, completion of a designated training course is required.

In order to obtain access, the individual must have an active record in the Human Resources database and an active email account.

For individuals who are not University employees, refer to Procedure 3501 PR.22 Non-Employees: Directory Listing and Access Privileges.

Access Must Reflect Current Business Needs

Access to restricted applications, functions, and/or data sets should always be limited to those that are required for the performance of an individual’s current duties, not those that were formerly appropriate or that may become so at some future data.

  • Whenever the individual’s duties at the University change, the individual’s access should also be changed to reflect this.
  • If the individual no longer needs any access (for instance, upon termination of employment), all access should be terminated.

See 5 – Monitor Employee Address and Request Modification When Appropriate

User Access Roles and Responsibilities

The process of requesting, monitoring and modifying access to Oracle financial and human resources applications involves the following roles and responsibilities:

Role

Responsibility

End user

  • based on consultation with supervisor, submits training and access request via Xtrain (central campus), or via department administrator (Medical School).
  • if request is approved, completes required training.
  • notfies training and access coordinator of any needed changes in access.

Training and access coordinator (TAC)

  • reviews and approves training and access requests.
  • monitors employee user access profiles; submits change requests if needed.

Process owner

  • reviews and approves training and access requests.
  • monitors user access; notifies relevant TACs of problems that require access changes.

START

  • allows users and training and access coordinators to request to add, change or delete access.
  • automatically modifies access based on requests.
  • sends access requests to User Accounts for set up where necessary.

User Accounts staff

  • sets up access requests that cannot be fulfilled automatically
  • routes START problems for correction
  • runs periodic quality assurance reports to identify employees for which user access corrections are needed;
  • notifies responsible TACs.

2 – Determine What Access a User Requires

Identify Applications, Functions and Data Needed

  1. A department administrator should identify those individuals whose tasks require access to Oracle financial and human resources applications, and determine the specific applications the individual will need to use.

  2. For each application, determine the specific functions and responsibilities for which the individual needs access. Bear in mind the sensitive nature of many restricted functions, and their potential for abuse and costly error, when making this determination.

Examples:

  • Employee E needs to be able to look up some items in an employee’s Human Resources file but does not need to see salary data and should not have access to it.
  • Employee F may need to view Human Resources information including salaries, but should not be able to enter or modify salary data.
  • Many people within a department may need access to data entry (sometimes known aspreparer) functions. Approval and authorization functions, on the other hand, should be more narrowly distributed, to ensure effective control and oversight.

3.      For each application and responsibility, define the maximum range of organizations, and, for HR and LD, the employee job categories, for which the individual will need access. These ranges will determine the YAS values that will be used in setting up the requested access.

  • A user should have access to all the sets of data within an application needed to carry out the designated tasks, but not to data that is outside the scope of the individual’s responsibilities.
  • Note: The same YAS domains apply to all of the user’s responsibilities within an application. For example, if an HR user has access to the Job Category FAC (Confidential Job Categories domain), and has two different HR responsibilities, he/she will have access to FAC for both responsibilities.

3 –Request Training and Access

Submit Request

Individuals must complete specific training courses in order to receive access to Oracle financial and human resources applications.

Submit requests for training and access as follows:

Department location

Request method

Central campus

  • End users or training and access coordinators submit training and access requests via the Xtrain web site:https://xtrain.its.yale.edu/xtrain/.
  • Information about courses is provided on the web site.

Medical School

  • Departments submit training and access requests to the Medical School Business Office.

 

Notification

Users receive e-mail notification of course registration. On completion of each course, users receive the appropriate Oracle access.

4 – Approval Process and Guidelines

Approval Process

The approval process for Oracle training and access requests is as follows:

  1. The designated Training and Access Coordinator (TAC) for each department or cluster of departments reviews and approves requests. For most departments, this is the business manager or department administrator.
  2. After TAC approval, some applications require additional approval by a process owner. In such cases the appropriate process owner is automatically notified via e-mail.
  3. Once required approvals have been granted, requests for training and access are forwarded to Xtrain registrars for course enrollment. Employees are notified via e-mail.
  4. Access request is sent automatically from Xtrain to START for automatic set up or is passed from START to User Accounts for manual set up if necessary.

TAC/Process Owner Approval Steps

TACs and process owners review and approve Oracle training and access requests as follows:

  • receive e-mail notifications of pending requests for which approval is required. The notification includes a link to the Xtrain web site.
  • select the Xadmin menu option in Xtrain.
  • log on and review pending requests, as specified below; approve or reject.
  • If University-level access to the Data Warehouse is requested (View all Financial Information, View All Balance-Level Financial Information), the TAC must also complete the on-line Data Warehouse University Wide Access Request form (https://www-iisp1.its.yale.edu/si/ua/uaadmin/DWUniversityWideRequests.htm).

Guidelines for Approvers

Before approving a request for training and access, approvers should evaluate the impact that the requested access will have on the individual’s overall access to University data.

Use the following guidelines and examples to determine if the request should be approved:

  1. The individual has a current business need for access to the applications and functions specified in the request.
  2. The requested Oracle responsibilities are at an appropriate level for the user’s job and position.

Example A

Employee G is requesting access to JSA with Manager responsibility. Employee G is a C&T employee whose duties involve preparation of financial transaction documents but do not include authority to approve financial transactions.

It is probably not appropriate for Employee G to receive a JSA Manager responsibility.

Therefore, do one of the following:

  • change the requested responsibility to JSA User; approve the modified request; notify the supervisor and/or employee of the change.

or

  • consult with the employee’s supervisor and/or the employee to determine an alternative solution; modify the request accordingly and approve.

or

  • reject the request, and notify the supervisor and/or employee of the reasons.
  1. The request will give the user access to a range of data that is necessary and appropriate for his/her duties.

If a user has access to two or more applications that share the same YAS values, he/she will have access to the same sets of data for all of these applications, for any responsibilities that he/she has been given within these applications.

Example B

Employee H currently has access to JSA for Org 123456. He is now requesting access to VIP for Dept X, which includes Org 123456 and Org 123457.

JSA and VIP share the same YAS Access Organization values. If Employee H’s access request is approved, Org 123457 will be added to his YAS Access Organization values. He will then have access to both Org 123456 and Org 123457 for both JSA and VIP.

If…

Then…

it is necessary and appropriate for Employee H to have access to data forboth organizations for his JSA and VIP responsibilities

  • approve the request.

access to data for both organizations for both JSA and VIP is not necessary ornot appropriate for this employee

  • do one of the following:
    • modify the VIP request to specify only Org 123456 (same as JSA); approve the modified request; notify the supervisor and/or employee of the change.

or

  • consult with the employee’s supervisor and/or the employee to determine an alternative solution; modify the request accordingly and approve.

or

  • reject the request, and notify the supervisor and/or employee of the reasons.

Example C

Employee J currently has an HR responsibility that allows lookup including salaries for Org 123456, for Job Category CT. She is now requesting access to LD for the same Org, for Job Categories CT, MP and FAC.

HR and LD share the same YAS Confidential Organizations and Job Categories values. If Employee J’s access request is approved, Job Categories MP and FAC will be added to her YAS Confidential Job Categories values. She will then have access to C&T and M&P and Faculty data for both HR (with salaries) and LD.

If…

Then…

it is necessary and appropriate for Employee J to have access to both HR (including salary data) and LD data for all three job categories

  • approve the request.

it is not necessary or not appropriate for this employee to have access to all of these sets of data

  • do one of the following:
    • modify the request to specify Confidential Job Categories that are appropriate for this user both for HR and LD (for example, CT and MP but not FAC); approve the modified request; notify the supervisor and/or employee of the change.

or

  • consult with the employee’s supervisor and/or the employee to determine an alternative solution; modify the request accordingly and approve.

or

  • reject the request, and notify the supervisor and/or employee of the reasons.

5 – Monitor Employee Access and Request Modification When Appropriate

Review User Access Profiles

Training and access coordinators should periodically review employee User Access Profiles to ensure that each employee’s Oracle responsibilities and YAS access values are appropriate.

View User Access Profiles as follows:

  • In the START web site (www.yale.edu/start), select the Review Others Access menu item under Access for Others responsibility.
  • Enter the net ID of the individual whose access you wish to review.
  • Review on-line and/or print as desired.
  • Refer to Guidelines for Approvers to determine if access is appropriate.

Monitor Employee Status and Duties

Monitor the following types of events within the organizations for which you are responsible, to determine if individual user access needs to be modified or deleted:

  • termination of employment
  • change in employee duties due to:
    • reorganization of work within department
    • personnel changes within department
  • change in organization hierarchy and/or creation of new organization
  • establishment of new projects.

Request New or Changed Access

Take appropriate action as follows:

If…

Then…

an individual needs access to an additional Oracle application and has not completed training requirements

  • submit a request for new access as described in Section 3.

an individual needs access to an additional Oracle application and has completed training requirements for that application

or

an individual needs a different level or type of access in an Oracle application to which he/she already has access

or

an individual’s access to one or more Oracle applications should be cancelled

  • use START to request a change to the organizational values or job category values to which the user has access.
  • Select the “change” button on the dashboard screen next to the application (HR, GA, AP/PO)
  • Select the org(s) to add or remove on the following screen.
  • Select and approver.
  • Hit submit.  If you are the approver, the request will be granted automatically within seconds.  Otherwise, it will be granted after the approver submits approval.
  • Check on the status of your request by clicking on Review Requests Made by Me under Access for Others responsibility.

 

Use User Access Profile to Request Changes

For each employee whose access requires modification, run and print a User Access Profile Report from the START.

  • If the user has left Yale, click on the “delete” button on the dashboard screen next to the application (HR, GA, AP/PO)
  1. Select to delete each responsibility the user no longer needs
  2. To add a responsibility for which the employee has already completed the training requirement, see policy: http://www.yale.edu/ppdev/Procedures/isp/BypassingTraining/toc.htm (Link 1)
  3. To change access values to an existing responsibilities, select the “change button on the dashboard screen, as described above.
  4. If you are the approver for the delete request, the request will be processed automatically within seconds.  Otherwise, it will be routed to the approver for approval, then processed.

Receive Notification of Change

START sends an e-mail notification to the requester when the requested changes have been made.