Understanding Data Permission Security for HCM

Core Security Views

PeopleSoft delivers the following core security views for components tracking people:

See PeopleTools: PeopleSoft Application Designer

Transaction Security Data

Transaction data is the data that is being secured. Certain transaction fields on a transaction data row are used to secure access to that row. The data in these fields is called transaction security data. When the value of the transaction security data matches the value that a user can access (user security data), the system makes the entire row of data available to the user.

When the user accesses the component search page the security search view filters the data rows, displaying only the rows of data with the same transaction security values that the user has access to.

This diagram shows the Department field being used as transaction security data to secure the data of people in the organization in which the user only has security access to the workers in department 123:

This table lists where you enter and maintain transaction data, to which record the transaction data is saved, and which fields can be used as transaction security data:

See (Classic) Adding a Person.

See Controlling Data Access for POIs Without Jobs.

See (Classic) Adding Organizational Instances.

User Security Data

User security data is the data about a user's security access. It enables the system to ensure that users have access only to that which you have granted them access. User security data for HCM data permission is the data permission that you assign to permission lists and the roles and users to whom you assign the permission lists.

Data permission is granted to row security (tree-based) permission lists (ROWSECCLASS) and regular (role-based) permission lists (CLASSID). Both permission lists are created using the Permission Lists component and Copy Permission Lists component.

When you create a permission list on the Permission Lists component you can assign security to a number of different aspects of the application. Data permission is assigned separately on the Security by Dept Tree page and Security by Permission List page.

This diagram shows that permission lists are created, assigned data permission (using either security by department tree or security by permission list), and then assigned to a user directly on the User Profile - General page as the Row Security permission list or assigned to a user on the User Profile - Roles page by assigning roles to the user, which are associated with permission lists:

This table lists the key differences between role-based permission lists with data permission and row security permission lists:

This diagram shows the search page determining which permission lists a user has and what data permission the list gives the user. The user, TRN, is associated with the permission list TRAIN for both row security and permission lists through roles. Since permission list TRAIN is granted access to worker's records in department 123 only, the search results will display only those workers from this department:

This table lists where you enter and maintain user security data and to which record the user security data is saved:

See Understanding PeopleSoft Security.

See Setting Up and Assigning Tree-Based Data Permission.

See Assigning Role-Based Data Permission Security to Permission Lists.

Transaction Security Join Tables

Each transaction security join table stores the transaction data required to secure each row of data. The security join tables store one row of data for each unique combination of key fields.

There are four transaction security join tables:

The key fields are:

• SCRTY_TYPE_CD (security access type code)

  Security access types indicate which field is used for transaction security data. For example the security type 002 enables you to secure person data by location.

  Security access types are unique to a security access set.

• SCRTY_KEY1, SCRTY_KEY2, and SCRTY_KEY3 (security keys)

  The key security fields uniquely identify the security transaction data securing a row of data. The system determines the key fields by the security access type. For example, if person data is secured by location, then the key security fields are BUSINESS_UNIT (the prompt value for location) and LOCATION (the third key field isn't required for this example).

• EMPLID

  A person's unique identifying number that is assigned to them on the Personal Data pages.

• SETID and DEPTID

  A department's set ID and department ID.

• HRS_JOB_OPENING_ID

  A job opening's unique identifying number, which is assigned to it on the Job Opening page.

Each table stores additional fields depending on the type of security you are using.

For example, if you are securing the data of people with jobs using the security access type Job Department Tree (001), the key fields of the security join table SJT_PERSON looks like this:

If you used two security access types, for example Job Location (002) and Job Department Tree, SJT_PERSON looks like this:

When you first enable a security access type, load the transaction data into security join tables using the SJT Refresh process. After the initial load, the system updates the tables using SavePostChange PeopleCode when you make a change to the transaction security data in the transaction components. You can also capture any changes the PeopleCode misses by running the SJT Refresh process as needed or the Nightly Refresh process.

This graphic illustrates how the transaction security join tables are kept up to date, as described above:

See Nightly SJT Refresh Process Page.

See Refresh Trans. SJT tables Page.

User Security Join Tables

The user security join tables store the user security data required to determine users' data permission. The security join tables store one row of data for each unique combination of key fields.

There are two user security join tables:

In addition to the security access type field and security key fields, the user security join tables store the following fields:

• SCRTY_SET_CD (security set code)

  A security set is a set of data secured in HCM. For example, PPLJOB is the security set for the data of people with jobs and DEPT is the security set for the department data. Each security set has security access types.

• OPRID

  The user's user ID.

• CLASSID

  The ID of the role-based or row security permission list.

  Note: The security join tables store row security permission lists (ROWSECCLASS) as CLASSID permission lists but identify them using a row security flag.

The permission list data in SJT_CLASS_ALL comes from two sources:

• SCRTY_TBL_DEPT

  When you add tree-based data permission to a permission list, you use the Security by Dept Tree page and the system saves the permission list information to the SCRTY_TBL_DEPT record.

• SJT_CLASS

  When you add non-tree based data permission to a permission list, you use the Security by Permission List page and the system saves the permission list information to the SJT_CLASS record.

For example, if you are securing the data of people with jobs using the security access type Job Department Tree (001), the key fields of the SCRTY_TBL_DEPT table look like this:

To load the data from the SCRTY_TBL_DEPT table, you need to run the Refresh SJT_CLASS_ALL process. In SJT_CLASS_ALL, the Refresh SJT_CLASS_ALL process:

• Creates a row of data for each enabled, tree-based security access type (and it's security set) with the data permission you set up on the Security by Dept Tree page.

  For example, if you enable security access type 012 (RS Dept Id) and security access type 001 (Job Department Tree) and grant the row security permission list TRAIN data permission to department 123, the process will create a row for each security access type and the permission will have access to people with jobs in department 123 and job openings in department 123.

• Saves the row security permission list as a CLASSID permission list.

• Saves the department set ID as SCRTY_KEY1 and the department ID as SCRTY_KEY2.

If you are securing the data of people with jobs using the security access type Job Location (002), the key fields of the security join table SJT_CLASS look like this:

When you save your changes on the Security by Permission List page, SavePostChange PeopleCode automatically updates the data to the security join table SJT_CLASS_ALL.

If you are using both security access types, SJT_CLASS_ALL looks like this after you have run the Refresh SJT_CLASS_ALL process and the PeopleCode has updated it:

This graphic illustrates how the permission list user security join tables are kept up to date, as previously described:

See Refresh SJT_CLASS_ALL Page.

The security join table SJT_OPR_CLS stores the relationship between User IDs and permission lists with data permission. The data in SJT_OPR_CLS comes from three sources:

• PSOPRDEFN

  This record contains the relationship between the User ID and row security permission list from the User Profile - General page.

• PSROLEUSER

  This record contains the relationship between the User IDs and roles from the User Profile - Roles page.

• PSROLECLASS

  This record contains the relationship between roles and permission lists from the Roles - Permission Lists page.

To update SJT_OPR_CLS with the data from PSOPRDEFN, PSROLECLASS, and PSROLEUSER, run the Refresh SJT_OPR_CLS process whenever you add a permission list with data security to a user profile (either by adding a row security permission list on the User Profile - General page, by adding a role-based permission list with data permission to a user-assigned role on the Roles - Permission Lists page, adding a role with data permission on the User Profile - Roles page, or by creating a new user profile by copying an existing one) or delete one from a user profile.

This graphic illustrates this process of when to update the user profile security join table:

The Refresh SJT_OPR_CLS process loads the OPRID and ROWSECCLASS values from PSOPRDEFN directly into SJT_OPR_CLS, saving the row security permission list as CLASSID.

To establish the relationship between user profiles and role-based permission lists, the process first loads the OPRID and ROLENAME from PSROLEUSER and the ROLENAME and CLASSID from PSROLECLASS into a temporary table (ROLEUSER_ROLECLASS) and then loads the OPRID and CLASSID, and the relationship between them, into SJT_OPR_CLS.

This diagram illustrates the data stored in SJT_OPR_CLS and their source as described above:

See Refresh SJT_OPR_CLS Page.

Enabling and Using Multiple Security Access Types

When you grant a permission list access to data in a security set using more than one security access type the security access creates a union, not a join or an intersect, with the two types. For example, if you enable the Job Company and Job Business Unit security access types for the PPLJOB security set and grant a permission list access to people in company A and people in business unit B, users with the permission list can access people in company A or people in business unit B; their access is not restricted to people in both business unit B and company C.