Security Sets and Security Access Types

A security set is a grouping of data that is being secured. The sets differ by the origin of the transaction security data. For example, people of interest without jobs have a separate security set from people with jobs because the transaction data used to secure them does not come from the JOB record, but from the PER_POI_SCRTY record.

PeopleSoft delivers the following five security sets:

Security Set Description Security Join Table Storing Data

PPLJOB

People with Jobs

Includes the data of any person who has a JOB record and all the associated data for that person.

SJT_PERSON

PPLUSF

People with Jobs for United States Federal Government

Includes the data of any person who has a GVT_JOB record and all the associated data for that person.

SJT_PERSON_USF

PPLPOI

People of interest without jobs

Includes the data of any person who does not have a JOB record and all the associated data for that person.

SJT_PERSON

DEPT

Departments

Includes department budgets and positions.

SJT_DEPT

RSOPN

Job Openings

Includes the data of job openings, including the data of applicants associated with a job opening.

HRS_SJT_JO

GPSPOST

German Public Sector Post Management

GPS_PM_CFG_SJT

TBHTMPL

Template Based Hire

HR_TBH_CFG_SJT

Note:

PeopleSoft has delivered all the security sets you are likely to need. If you add new sets, it is considered a customization.

See Security Set Table Page.

Security access types are ways of securing the data within a security set. Each security set has a number of security access types that you can choose to enable. Among other things, security access types determine:

  • The security transaction data.

  • If there is data security for future-dated rows.

  • If the access type uses a department security tree.

    Note:

    You can only set up department hierarchies on security trees and you can only grant security access by department tree to row security permission lists.

    Security access types that don't use a department security tree do not have a hierarchical structure and require that you list each field value individually for each permission list.

The following table lists the security access types by security set:

Security Set Security Access Types

PPLJOB

  • Job Department Tree (001)

  • Job Location (002)

  • Job Business Unit (003)

  • Job Company (004)

  • Job Reg Region (005)

  • Job Salary Grade (014)

  • Person Organization (015)

  • Job - Deptid - non Tree (025)

  • Job Company/Paygroup (032)

  • Group Build (045)

  • Matrix Team (046)

PPLUSF

  • US Federal Department Tree (016)

  • US Federal Location (017)

  • US Federal Company (018)

  • US Federal Business Unit (019)

  • US Federal Salary Grade (020)

PPLPOI

  • POI Business Unit (006)

  • POI Location (007)

  • POI Institution (008)

  • Person of Interest (009)

DEPT

  • Departments by Tree (021)

  • Departments - non Tree (022)

  • Departments by Set ID (023)

RSOPN

  • RS Company (010)

  • RS Business Unit (011)

  • RS Dept Id (012)

  • RS Location (013)

  • Recruiting Team (031)

GPSPOST

GPS Post Management (037)

TBHTMPL

  • Template ID (033)

  • Template Category (034)

  • Person Organisation (035)

  • Country (036)

  • Template Transaction Type (038)

Note:

PeopleSoft has delivered all the security access types you are likely to need. You can add new types but it requires a very good knowledge of the application and of SQL.

Security administrators can only assign data permission using the security access types that you enable.

See Security Type Table 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.

Note:

See the security technical brief posted on My Oracle Support for information about creating security access types that join transaction fields to secure data.