- Peoplesoft Functional
- Peoplesoft Technical
- Database (Oracle)
- Tips and Tricks
- Interview Questions
- Peoplesoft Functional Interview Questions
- Workforce Development Questions
- Workforce Administration Questions
- PS PayRoll
- Recruiting Questions
- Security Questions
- Benefits Questions
- Setup HRMS Questions
- Other Functional Questions
- Peoplesoft Technical Interview Questions
- PeopleCode Questions
- Component Interface Questions
- Application Engine Questions
- SQR Questions
- PeopleSoft Mixed Questions
- PeopleSoft Certification Exam Questions
- Security Questions
Security Tree A security structure that graphically represents the hierarchy of your organization.
Tree Level Represents a logical division in your business hierarchy (ex: department, branch or region).
Tree Node Represents an organizational entity on the tree.
Tree Manager A PeopleSoft tool that provides a visual means to build a hierarchy of security for all organizational entities.
Query Trees Graphical representation of Tables to which you wish to control query access.
Access Groups Nodes in Query Trees where you would group Operators and assign them access to all tables under the node.
User Profiles: A User Profile describes a particular user of the PeopleSoft system.
User Profiles define individual PeopleSoft users. You define User Profiles and then link them to one or more Roles. Typically, a User Profile must be linked to at least one Role in order to be a valid profile. User Profiles maintain the Roles that are assigned to the user.
Roles are assigned to User Profiles. Roles are intermediate objects that link User Profiles to Permission Lists. Multiple Roles can be assigned to a User Profile, and you can assign multiple Permission Lists to a Role. Some examples of Roles might be Employee, Manager, Customer, and so on.
Permission Lists are lists, or groups, of authorizations that you assign to Roles.
Permission Lists store Sign-on times, Page access, PeopleTools access, and so on.
A Permission List may contain one or more types of permissions. The more types of permissions in Permission List the more modular and scalable your implementation.
A User Profile inherits most of its permissions through the roles that have been assigned to the User Profile.
Data permissions or row-level security appears either through a Primary Permission lists or a Row Security Permissions list.
Row-level security controls access to the subset of data rows within tables the user is authorized to read or update. The decision to implement row-level security will be based on the need to provide that level of data security. To establish row level security, you must first decide the necessary data security level required, which key fields to secure, and whether security will be defined through User IDs or Permission Lists. With row-level support, PeopleSoft security can restrict individual users or Permission Lists from specific rows of data that are controlled by key fields.
– Business unit
– Set ID
– Ledger (and ledger group)
Therefore, users would only be able to view those rows for which they have security access for a specified Business Unit or Project, for example. Once row level security is turned on in for a particular PeopleSoft module, it applies to all applications within that module, not specific applications. Additionally, a method for implementing row-level security can be by User ID. Key fields can be associated to User IDs as well as Projects. Projects will also perform row-level security by User ID through the Use List. This sets up Projects to implement row level security in a team-based method.
PeopleSoft security mainly depends on Rowlevel security.
Security works best if it is based on organizational structure.
Types of security supplied by PeopleSoft:
– Departmental security
– No security
– International security
3 steps in setting up department security:
– Create the security tree
– Update department security tree
– Grant and restrict access to the entities
Last Updated (Sunday, 18 April 2010 04:07)