All Oracle Applications users access the system through a responsibility that is linked to a security group and a security profile. The security group determines which business group the user can access. The security profile determines which records (related to organizations, positions and payrolls) the user can access within the business group.
There are two types of security profile:
A responsibility with an unrestricted security profile has unrestricted access to data in Oracle HRMS tables. It connects to the APPS Oracle User. If you connect to an unrestricted security profile, the data you see when you select from a secure view is the same data you see if you select from the table on which the secure view is based.
When you connect to the APPS Oracle User with a restricted security profile you can access the secure tables directly if you want to bypass the security restrictions defined in your security profile. You might want to do this to perform uniqueness checks, or to resolve foreign keys.
Restricted security profiles can optionally make use of read-only, or reporting users. These are separate Oracle Users, one per restricted security profile, that have read-only access to Oracle tables and views. Reporting users do not have execute privilege on Oracle HRMS PL/SQL packages, and do not have direct access to the secured Oracle HRMS tables.
How Secure Views Work
The information that is visible through a secure view depends on the definition of the security profile through which the view is being accessed.
If you have connected with a restricted security profile the information you can see is derived from denormalized lists of organizations, positions, people and payrolls.
The lists are used only when required. For example, the payroll list is empty for a security profile that can see all payrolls, and in the case of a security profile that can see all applicants but a restricted set of employees, the Person list contains employees but no applicants.
If the HR:Cross Business Groups profile option is ‘N’, the secure views return data only for the current business group.
If the HR:Cross Business Groups profile option is ‘Y’, the secure views return data for all business groups, subject to any further restrictions that apply by virtue of the current security profile.
Three processes are used to implement Oracle HRMS security:
- Grant Permissions to Roles (ROLEGEN)
- Generate Secure User (SECGEN)
- Security List Maintenance (PERSLM)
ROLEGEN runs automatically as part of an installation or upgrade. If you are not setting up reporting users, you need not run SECGEN.
Refer to the topic on Security Processes, Oracle HRMS Configuring, Reporting, and System Administration Guide for details of how to submit SECGEN and PERSLM from the Submit Requests window. This section describes how the processes work.
A role is a set of permissions that can be granted to Oracle users or to other roles. Roles are granted to users by the SECGEN process (see below).
The ROLEGEN process must run before you run SECGEN. ROLEGEN dynamically grants select permissions on Oracle HRMS tables and views to the HR_REPORTING_USER role. This role must exist before ROLEGEN runs.
The HR_REPORTING_USER role is created during the install of Oracle HRMS. ROLEGEN is run during the install of Oracle HRMS.
Note: As ROLEGEN runs as part of the installation and upgrade processes, you do not need to run ROLEGEN manually.
ROLEGEN performs the following actions:
- Creates public synonyms for HRMS tables and views, excluding unsecured tables (%_ALL_%)
- Revokes all existing permissions from HR_REPORTING_USER roles
- Grants SELECT permissions to HR_REPORTING_USER role for HRMS tables and views
You run SECGEN for a specified security profile. It grants the HR_REPORTING_USER role to the Oracle User associated with the security profile.
SECGEN must be run after ROLEGEN. However, once SECGEN has been run for a particular security profile, you need not rerun it even if ROLEGEN is run again.
SECGEN is a PRO*C process with embedded SQL statements. You initiate it from the Submit Requests window.
You should run PERSLM periodically (for example, nightly) to refresh the security lists upon which the secure views are built.
Important: This process has the capability to run multi-threaded, allowing it to take advantage of the capabilities of your hardware.
PERSLM is a PL/SQL procedure that you submit from the Submit Requests window. It builds the required security lists based on the restrictions defined for the security profiles being processed.