UCPATH HCM SECURITY APPROACH
University of California
PeopleSoft HCM Implementation
Date:
July 2013
Version:
1.0
Page 1 of 13
Document Control
Change Record
Date
Author
Version
Change Reference
July 2013
August 2013
Biv Ramlukan
Randy Wilson
1.0
1.1
Initial release
Incorporated feedback from Eric Goodman
Reviewers
Name
Position
Anthony Lo
Mark Cianca
Randy Wilson
Pat Furze
Doug Johnson
Sharon Arce
UC Project Manager
UC Interim CIO
UC Implementation Lead
UC IT Lead
Oracle Project Manager
Oracle Technical Project Manager
Page 2 of 13
Contents
Document Control ..................................................................................................................... 2
Introduction ............................................................................................................................... 4
Purpose ............................................................................................................................... 4
Out of Scope for this Document ........................................................................................ 4
Key UCPath Security Principles ......................................................................................... 4
Assumptions ....................................................................................................................... 5
UCPath Security Overview ........................................................................................................ 6
Technical Design ................................................................................................................ 7
Role Matrix ......................................................................................................................... 8
Security Administration ..................................................................................................... 8
Dynamic Security ............................................................................................................... 9
Security Maintenance ...................................................................................................... 10
Row Security..................................................................................................................... 10
Query Security .................................................................................................................. 10
Batch Security .................................................................................................................. 11
Security Delegates ........................................................................................................... 11
Security – Business Perspective ....................................................................................... 11
Page 3 of 13
Introduction
Security is critical for any PeopleSoft application. Typically, organizations do not allow any
one department to have access to all of its applications. Similarly, they would not want
everyone within a department to have access to all the functions or all the data of that
particular application. In addition, the ability to customize the application objects, and
change core and configuration data must also be controlled.
PeopleSoft security allows organizations to set up controls within the system to limit what
functions and tasks a user can perform as well as ensure that sensitive data, such as
employee salaries, performance reviews, social security numbers, home addresses and
phone numbers are protected. PeopleSoft security works with other network and database
security to protect the PeopleSoft system from unauthorized access.
Purpose
The purpose of this document is to provide the strategy for the UCPath specific application
security for PeopleSoft Human Capital Management (HCM) This strategy is a high level view
of the approach to developing access and data security for the UCPath application and will
inform the operational application security processes and procedures to be developed in
order to support the system. This document focuses on outlining the approach to defining
the application security architecture and the principles driving decisions related to security
and access. It is recognized that there will be additional security requirements identified,
related to specific locations, job function and data. The flexibility in the application's
security design provides for capabilities to support a balance of access and security.
Out of Scope for this Document










Database Encryption
Network Security
Database Security
Web Security – (e.g. SSL)
Workstation Security
LDAP Integration
Web Services Security (Encryption)
Portal Security
Oracle Identity Federation integration
Enwisen Security
Key UCPath Security Principles
The following are the key UCPath security principles that inform and drive decisions related
to security and access:



Job functions will change. As such, current security and access will be evaluated
and will adjust to align with the changes in job function.
Users will have application access only to the functions required to support their
job.
Users will have access to only the population of employees they are authorized to
view.
Page 4 of 13



Reporting access will be split into Report Writers and Report Viewers.
Change management procedures will be established for the provisioning and deprovisioning of access.
Business processes established during the implementation phase will be carried
over to production.
Assumptions




Security will be based on business processes, job duties, responsibilities and
positions, not individual users.
Key functional users will be knowledgeable in the individual job tasks and duties for
their functional area.
The UCPath Project functional leads will be responsible for defining the access
requirements for each area. The UCPath Project security lead will provide a
template of the application navigation menus to the functional leads.
Administration tasks will be divided between administrators at UCPath and at the
campus level. The tasks will be later defined based on the available resources.
Page 5 of 13
UCPath Security Overview
Security Architecture
The UCPath security model was designed using a Risk Based Approach. In this type of
model, the primary objective is to isolate and focus administration on sensitive data and
processes. A secondary benefit is a reduction in the overall administration effort to maintain
security across multiple locations and departments.
All Roles and Permission lists, custom and delivered, will be established to ensure that
duplicate and redundant access will be eliminated.
A user profile is required to access the PeopleSoft application. Each employee will be
assigned a unique user profile with access to pages and processes required to do their job.
In PeopleSoft Security Architecture, Pages are attached to Permission Lists, which are then
attached to Roles. Access is granted to user, by assigning a Role to the employee’s User
Profile.
PEOPLESOFT+ARCHITECURE
USER+PROFILE
ROLEs
PERMISSION+LISTs
PAGES
Functional Design
User profiles will be created for each user requiring access to PeopleSoft. Security Roles will
be built using roles based on the application access they need in order to perform their jobs
within PeopleSoft.
A standard set of Security Roles will be created for each functional area. The functionality
contained within each security role will be defined by UCPath SME’s and will incorporate
feedback received from each Location’s functional Subject Matter Experts (SMEs) along
with appropriate audit/control stakeholders. Standardizing security roles for each functional
area simplifies the Access Request procedure.
Dynamic Roles
To reduce the administration overhead, PeopleSoft Dynamic Role Assignment will be used
to provision and de-provision roles for a user based on defined business rules. The dynamic
role functionality will automatically assign a role based on the employee’s job/position (Base
Employee and Core Functional roles) to users when they are hired, without the need for an
administrator. Additional manual intervention is usually required to finalize many
employees final security access within the application. This is a delivered feature.
Page 6 of 13
Technical Design
Permission Lists
Permission lists will be identified by the following prefixes:
o
UC_ALL – identifies Master permission lists that contain all access to all pages of
the Parent menu folder.
o
UC_P – identifies Public permission lists, which are similar to the Master permission
lists, but do not contain access to sensitive data.
o
UC_R – identifies sensitive pages that have been removed from the Master
permission lists and have a 1:1 ratio between a sensitive page and its associated
permission list within all UC_### permission lists.
o
UC_RS – identifies Row Security permission lists that will grant a user access to
specific departments in the department tree.
PeopleSoft Security Profile Roles
The security roles and permission lists are developed using a Risk Based approach intended
to isolate and restrict application access to Sensitive Pages and grant access to the
remaining pages that are considered safe to be shared by the main functional areas. An
individual may have one to many roles, depending on their functional access and
responsibilities.
Sensitive Pages
Pages that are identified as sensitive are assigned to their own permission lists. The pages
are also removed from all other permission lists being used to ensure that access to the
sensitive page can only be granted through a single permission list. This creates a one to
one relationship between page and permission list. This method removes redundant or
duplicate permissions and simplifies the administration process. The Security
Administrator(s) will only have to add a single permission list to a user’s role when access is
requested.
The security model will contain three specific role types as described below:
Base User Role
The Base roles are a group of non-sensitive permission lists and will be assigned to all
employees dynamically.
The Base Role will provide access to Employee Self Service menus such as Personal
Information, Benefits Summary, Emergency Contacts, W2 and I9 forms
Core Functional Role
The Core roles are a grouping of non-sensitive pages that are approved for all users within
that functional area. For example Benefits, Payroll and HR will each have a separate Core
role.
Segregation of Duties Role (SOD)
The SOD roles are a grouping of sensitive pages providing access for a Job or System
Function. It should only be assigned to users within an office that have been approved to
access the sensitive pages. For example, the ability to update the Job InformationCompensation page or Run the Payroll Process will be limited to only a select group of
employees at the UCPath Center. These functions will therefore be built into SOD roles and
only assigned to authorized users.
Page 7 of 13
Role Matrix
The Role Matrix below is an example of roles and the page permissions that will be
associated to each role. In a facilitated process to be led by the UCPath PMO, each
functional area will determine the final Role Names. The roles will be assigned permissions
based on the feedback provided by the project functional leads in collaboration with UC
users, who will need to determine the type of actions allowed (Read, Update, Correction)
for each page that each role should have.
The number of roles that can be defined to support a functional area is not limited, allowing
Specialized Roles as described below to be created:
The HCM application does not limit the number of roles that can be defined and created;
within each functional area, there are also Specialized Roles as described below:

Core Role – functionality that is approved for all users within a functional area.

Master Role – access to all functions within a functional area. Used for testing and
for leads.

Delegate Role – access to a specific page or function for the purpose of supporting
principal users.
The following table is an example of the UCPC roles that will be created for the users
administering Benefits:
UCPC Level 1
Rep
UCPC Level 2
Manager
UCPC Level 3
Analyst
Review ABBRs
Read
Read
Read
Review HR/Job/Payroll Data
Read
Read
Read
Update ABBRs
Read
Update
Correct History
Update
Update
Correct History
Health Benefits
Read
Read
Correct History
Savings Plans
Read
Read
Correct History
Update
Update
Update
Run Automated Event Processing
None
Update
Update
On-Demand Event Maintenance
None
Update
Update
COMPONENTS/ROLES
BENEFITS
Employee/Dependent Information
Update Dependent/Beneficiary
Enroll In Benefits
Manage Automated Enrollment
Participant Enrollment
Perform Election Entry
Events
Security Administration
Security Administration tasks will be shared between the Security Administrator(s) at the
Systemwide and Campus levels, with their primary functions being different.
The Systemwide Security Administrator will be responsible for building and maintaining
new roles and permissions lists as required by the campuses, audit reporting, and executing
Page 8 of 13
security tasks that have a global system effect. Depending on the complexity these may be
developed within the systems testing environments and released into production through
the Release Management Process after a Quality Assurance process is executed.
Campus Security Administrators will be responsible for provisioning and deprovisioning of
security roles. This separation of duties will allow Campus Security Administrators to
respond to their local users while the systemwide shared services function monitors and
maintains overall integrity of the existing security model.
Distributed User Profiles
PeopleSoft’s delivered Distributed User Profile functionality provides separation of duties
required to support the following AWE:









Initiator
Approver 1
Approver 2
Approver 3
SMG Approver
UCPath Approver
AWE Approver Setup (number will vary from campus to campus )
AWE Administrator (a very small number at each campus)
Remote Security Administrator
For example the Remote Security Administrator will be responsible for provisioning and
deprovisioning roles, but will not be able to make updates to the roles. The UCPath
Administrator will maintain the content roles and permission lists.
Dynamic Security
Dynamic Role Assignment
Dynamic Roles are a delivered feature of the PeopleSoft application security.
Dynamic Role Assignment will be used to automate the provisioning and de-provisioning of
user roles based on a set of defined business rules. The rules can be built to identify
Department, Manager, Position, Job Code or a combination of these attributes that can be
associated to a specific role.
For example, if an employee changes jobs and becomes a manager in a new functional area:
when the dynamic rule runs, the system removes the roles associated with the employee's
previous functional area and adds the appropriate roles required for the new functional
area.
The use of Dynamic Role Assignments can significantly reduce the administration effort
required to maintain security across multiple functional areas. It also mitigates the risk of
users retaining function-specific security roles after they are no longer associated with a
functional area.
It is acknowledged that additional manual tuning of the final roles in addition to the
automated assignment by DRA may be needed based on the specific user’s security
requirements.
Page 9 of 13
Security Maintenance
Administration Tasks
The following table contains a list of security-related administration tasks and a commonly
used design of potential responsibility for the building and administration of those tasks.
The table below identifies who will administer each area of security:
ADMINISTRATION TASKS
DESCRIPTION
System Wide
Security Standards
Building and maintaining Roles and Permission Lists.
Security Role Assignments
Provisioning and de-provisioning of roles for UCPath Center.
AWE Maintenance
Maintenance of AWE related roles.
AWE Administration
Assignment of AWE related roles.
Query Tree
Building and maintaining query trees and access groups.
X
Department Tree
Building and maintaining department tree for locations.
X
Batch Security
Administration and monitoring of batch jobs.
X
Row Security
Building and administration of row security permissions.
X
Reporting Tools
Building and maintaining of reports for locations
X
Campus
Location
X
X
X
X
Row Security
Row Security
Row security is an independent layer of security that specifically controls access to
Employee data. Even if a user has access to pages under JOB DATA, they must be setup
with row security in order for them retrieve employee information.
UCPath has implemented Department Tree based Row Security, which relies on the
Business Unit and its underlying department hierarchy. Row security permission lists must
be built with access to the Business Unit, which grant access to all the departments or grant
access only to specific departments. The Row Security design and implementation is
separate from the role access security that was discussed under the Role Matrix section of
this document, but the two security designs are dependent on each other and work
together to provide users access to their required pages, as well as the ability to view
employee data within those pages.
The design and build of the row security model matrix must also take into account the need
for:
A) Access to employee data that will be shared between Business Units.
B) Access to employee data that will be shared between departments within the same
Business Unit.
Query Security
Query Data Security
Query data security is an independent layer of security that specifically controls access to
the database tables when accessing these tables using PeopleSoft Query Viewer.
The Query Security Trees for UCPath will be designed with the same methodology
employed for application security. Tables that contain sensitive data (e.g., SSN,
Page 10 of 13
Compensation, DOB, etc.) will be segregated into their own groups to clearly distinguish
them from groups that contain public, non-sensitive data.
Similar to application security, the employee data that a user can see is determined by the
user’s row security. For example, in order for a user to run a report using PeopleSoft Query
Viewer with employee Job information, the user must have row security permissions
granting access to employees within a department and the user must be assigned access to
the JOB_DATA table.
The central team, working with the locations, will develop public queries and reports with
Query Manager. The results will be presented in collaboratively designed reports and
designated users will be assigned Query Viewer, which will allow them to run and view the
reports. Where necessary, location-specific queries and reports will be created.
Batch Security
Batch Environment Security
Batch processes may be run in a scheduled or ad hoc manner. For this project a third party
tool, Control-M, has been designated as the enterprise scheduler to initiate and track batch
process jobs. A profile will be created specifically to run batch jobs and will be independent
of any user. To satisfy SOD controls, a separate profile will be created for each functional
job set, e.g., Payroll, Benefits, etc.
Batch interfaces will be scheduled to run automatically based on their individual process
requirements. Access to Batch Security will only be granted to production support roles.
Security Delegates
Security Delegates
Delegate roles will be developed to support senior leadership users who wish to delegate
the approval or review of specific functions. These roles will be limited to accessing a
specific page or function and will not include access for the entire component functionality.
The functions identified by the functional leads will be used to develop the permission lists
and delegate roles.
Security – Business Perspective
The following tables contain an explanation of terminology used to describe the Security
Components, their associated functions and the systems in which user access will be
administered.
Terminology
Security Component
IDM / PeopleSoft User Profile
Department Security
(Row Level Security)
Business Unit
Description
The PeopleSoft User Profile is automatically established upon hire into UCPath system. Roles must be
removed from the PeopleSoft User Profile upon employee termination consistent with HR/HCM
business rules.
The Row Level Security determines the employee population that a user can see. The Department Tree
will drive UCPath Row Security, with a separate Department Tree representing each Business Unit. A
user could be assigned to all Business Units, all Departments within a Business Unit or only select
Departments within a Business Unit. The user will be able to see all employees with departments that
they have access to.
A business unit in PeopleSoft allows multiple businesses to be setup within the same instance. Each
Page 11 of 13
Query Trees
PeopleSoft Security Roles
‘Reports To’ Relationship
campus is identified by its own business unit in PeopleSoft.
PeopleSoft uses Query Trees to control reporting access to the tables in the PeopleSoft database.
Query Trees contain Access Groups to which the tables are assigned. Tables can be grouped together
inside an Access Group, by the type of data they contain or based on the data requirements of a
department.
 Standard security roles are defined, established and maintained systemwide. A person can be
assigned to multiple PeopleSoft security roles.
 Security roles are both automatically and manually assigned to people.
Automated Security Roles
o Upon hire all employees will be assigned a security role that allows them access to employee
inquiry and self service.
o Employees will be assigned a security role that allows them access to the Manager Dashboard
when a ‘reports to’ relationship is established. This security role will be removed when the
‘reports to’ role is removed.
‘Reports to’ information will be managed/maintained by the locations via the Position Management
functionality in PeopleSoft.
Page 12 of 13
Sample Security – Business Perspective
System Component
Description / Examples
Security Component Utilized
EMPLOYEE POPULATION
PSFT Report
HR Admin /
User
Power User
All
Employees
Manager
X
X
UC Path Portal
Entry point to Knowledge
Management, Case
Management, and all
PeopleSoft Functions
 IDM - Network ID (Single
Sign-On)
Person level Data* Visa/Permit
* Security Clearance
* Person Checklist
* Disabilities
Pages used to enter employee
Citizenship/Visa, Background
Check, E-Verify and employee
Checklist data.
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
X
X
Person Org Summary
Inquiry page with global access
(No personal or pay data)
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
X
X
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
X
X
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
X
X
Person Profile
OPA Administrative
page
Employee Self Service
Position Data
Administrative page to enter
employee Person Profile
Information (Degrees,
License/Certifications)
Administrative page to enter
employee OPA information.
Used for SMG and
Deans/Faculty Admin.
Examples of self-service
functions include:
 Name/Address change
 Person Profile
 Benefits enrollment
 Direct Deposit change
Pages used to maintain
Position Data. Campuses will
have direct access to the native
pages.
Template Based Hire
* TBH Status Page
Templates used to Hire, Rehire,
Add Contingent Workers
Workforce Job
Summary
Inquiry page for campuses w/
security. This access is
controlled by a user’s
department security.
UC Employee Review
Page used to enter employee
review information
Assign Group Increases
Page used to review and
approve group increases
Manager Dashboard
*Org Chart Viewer
HCM related manager self
service transactions:
 Time Management
 Job Info
 Personal info
Manager Actions / AWE
Ability to approve, deny
transactions
HR Analytics
PeopleSoft Query
(Pre-defined)
Provides Workforce
Information on employees for:
 Employee Performance
 Turnover
 Absenteeism
 Query Viewer – Launch
existing queries
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 Department Security
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 Department Security
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 Department Security
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 PeopleSoft Group
Security
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 ‘Reports To’ Relationship
 Access to Direct Reports
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 Custom AWE Workflow
Roles
 Department Security
X
IDM
PeopleSoft Security Roles
Query Trees
Department Security
X
X
X
X
X
X
X
X
X
X
X
X
X
X
(If
Approver)
X
 IDM/PeopleSoft User
Profile
 PeopleSoft Security Roles
 Business Unit Security




X
FIN/GL
Users
X
X
X
Page 13 of 13
X
X
X