Beruflich Dokumente
Kultur Dokumente
Definition Security: Use definition security to govern access to peoplesoft objects such as records, pages etc, and to protect particular object from being modified by a particular developer.
Application data Security: With application data security we can set up data permissions at the following levels. 1. Table level (For queries only) 2. Row level (Using security views) 3. Field Level Table level security: For each peoplesoft query user, we can specify the records the user is allowed to access. This is done by creating Query Access Groups in peoplsoft tree manager, and assigning users to these groups with PeopleSoft query security.
Row-Level security: We can design special views- security views to restrict access to individual rows of data. Row level security enables you to specify the data that a particular user is allowed to access.
Field Level security: Field level security is used to restrict access to a particular fields on page level. This is implemented using PeoplCode. E.g. restrict a particular set of users from accessing compensation rate field, use Peoplecode to make it display only or invisible. Peoplsoft authorization IDs : User IDs : User id is the unique id assigned to each user, this id is used by the user to access the online peoplsoft system Connect ID: Connect ID performs initial connection to the database. Peoplsoft no longer creates users at database level. It is a valid user id that, when used during sign-in, takes place of peopleSoft user id. Using connect id means that you dont have to add a new user id for every new user you add to the system. Access ID: When we create any user id we should, assign it to an access profile, which specifies an access id and password. Access id is the RDBMS id with which the peoplsoft applications are ultimately connected to the database after peoplsoft system connects using connect id and validates userid and password. User Id and Connect Id have access to only few peoplsoft tables, and that access is select only. Access profiles are not used when user access peoplsoft system using Pure Internet Architecture. During a PIA transaction, the application server maintains a persistent connection to the database, the end user leverages the access id that application server domain used initially to sign in to the database. Most sites use only one access profile.
Symbolic IDs: Peoplsoft encrypts access id before it stores it in peoplsoft security tables. So when the access id which is stored in PSACCESSPRFL, the query selects the appropriate access id using the symbolic id as search key. All the user ids are associated with the symbolic id, which in turn is associated with the access id. User Id ---- Symbolic Id --------- Access ID (stored in PSACCESSPRFL in encrypted form) Administrator Access:
Permission List
Permission lists are the building blocks of user security authorizations. Recall that roles are intermediary objects between permission lists and users. You use roles to assign permissions to users dynamically. Setting Up Process Permissions: As we can define permissions for pages users can access, it is critical to tp specify for Batch( and online ) processes that users can invoke using Process Scheduler. When we create Process Permission List, we add appropriate Process Groups so that users belonging to a particular role can invoke the proper batch programs to complete the business processes. We do this using process group permission page. We use process profile permission page to specify when a user or role can modify certain process scheduler settings. Process Group Permission Page: To define which process groups process can be invoked by users of certain roles (Roles having this permission list). This page lists the process groups that are associated with the permission list. Users can run only the processes that belong to process groups assigned to their roles. Process Profile Permission Page: Whether certain user or role can change certain process scheduler settings
Setting Component Interface Permission: We grant access here to a particular permission, so that user belonging to that role has access to the component interface. We also need to grant access to component interface methods Setting Query Permissions: The permission list Query page has links to permission list access group page, where we can define records to which user can have access in PeoplSoft Query, and Query Profile page where we can define the query operations a user can perform. Permission List Access group page: Access groups are nodes in a query tree, which we build with peopleSoft tree manager. After building a query tree we can give users access to one or more access groups, using this page. They can generate queries on any tables in access groups accessible to them.
To add an access group to a permission list: 1. Open the permission list and select Query, Access Groups Permissions. 2. Select a tree name. 3. Select the highest access group that the user can access. The access group that you select should be the highest-level tree group to which this permission list needs access. 4. (Optional) Clear the Accessible check box. To grant access to most of the record components in a high-level access group, but restrict access to one of the lower-level groups, you can add a new row for the lower-level access group and clear the Accessible check box. Users can then access all record components within the higher-level group except for those you explicitly made inaccessible. 5. Save your changes.
Query Profile Page: Query profiles specify available query operations. You can give users the right to run queries but not create them, or to create regular queries but not workflow queries, and you can restrict the SQL operations that users can perform. You control these options through the query profile. Each permission list has its own query profile, and the combination of all permission lists that are assigned to a role determine the total query access for the role. User profiles inherit query access only through the roles that you assign to them.
Definition Permissions Grant access to the definitions that developers create using PeopleSoft Application Designer. Each type of object that you define with PeopleSoft Application Designer appears in the object permissions list.
Roles
Roles are an intermediate object that exist between permission lists and user profiles. Roles aggregate permission lists so that you can arrange permissions into meaningful collections. If you implement dynamic roles, then you can add permissions to users dynamically, which reduces administration tasks. Users inherit most of the permission lists from roles assigned to the user profile. However we assign following permission lists directly to user profile Data permissions. These are assigned through a primary permissions list or a row security permissions list. PeopleSoft Navigator homepage permissions. Process profile permissions.
Access Profiles: The access profile is the profile that your users use to connect to your PeopleSoft database. Every user profile must be assigned an access profile, by way of a Symbolic Id. The Access Id consists of a RDBMS Id and Password, and this id must have an administrators privileges Acess Ids are used in following situations. When an application server initializes and connects to the PeopleSoft database. When a developer or power user signs in to the PeopleSoft database directly (two-tier). When batch programs connect to the database.
Access Profile enable you to reduce the number of users who need to know system administrator password. In fact, only one person needs to know these passwords. That person can create the required access profilesby providing the necessary passwords, when promptedand all other security administrators can simply assign users to the pre-defined access profiles. The Access ID and password are encrypted in the database in the PSACCESSPRFL table. After we have created RDBMS ID with system administrator privileges, then we use peopletools access profile utility to link out RDBMS ID to the access profile. This is created when we first install our database.
Symbolic ID
The Symbolic ID is used as the key to retrieve the encrypted ACCESSID and ACCESSPSWD from PSACCESSPRFL. For initial installation, you should set it equal to the Database Name.
User Profiles:
Symbolic ID
Associated with a users encrypted access ID and access password. The correct symbolic ID must be entered to retrieve the appropriate access ID and password. This value determines which access ID and password are used to log the user onto the database after the system validates the user's user ID. The access ID is required only when a user needs to connect directly to the database (in two-tier). The access ID is not required with the portal or if you use a Lightweight Directory Access Protocol (LDAP) directory server to manage user IDs.
Permission Lists
Associated with PeopleSoft Workflow. Contains the permissions that a user requires for running batch processes through PeopleSoft Process Scheduler. For example, the process profile is where users are authorized to view output, update run locations, restart processes, and so on. Note. Only the process profile comes from this permission list, not the list process groups.
The system determines which data permissions to grant a user by examining the primary permission list and row security permission list. Which one is used varies by application and data entity (employee, customer, vendor, business unit, and so on). Consult your application documentation for more detail. The system also determines mass change (if needed), and definition security permissions from the primary permission list.
Find
If you are looking for a specific access group or a record you can use the Find Value page rather than drilling down into the tree. You specify an access group or a record or its description. You can select a case sensitive search and specify that an exact match must be found.
Row-Level Security:
With row-level security, users can have access to a table without having access to all rows on that table. This type of security is typically applied to tables that hold sensitive data. For example, you might want users to be able to review personal data for employees in their own department, but not for people in other departments. You would give everyone access to the PERSONAL_DATA table, but would enforce row-level security so that they could only see rows where the DEPTID matches their own. PeopleSoft applications implement row-level security by using a SQL view that joins the data table with an authorization table. When a user searches for data in the data table, the system performs a related record join between the view and the base table rather than searching the table directly. The view adds a security check to the search, based on the criteria youve set up for row-level security. For example, to restrict users to seeing data from their own department, the view would select from the underlying table just those rows where the DEPTID matches the users DEPTID.
4. Once youve set the query security record definition, click OK to close the Record Properties dialog box, then save the record definition. Note. PeopleSoft row-level security views restrict users from seeing certain rows of data. To secure data through the search record, simply put one of the three Row Level Security fields on the record as a Key, not a List Box Item. The three Row Level Security fields are OPRID (User ID), OPRCLASS (Primary Permission List), and ROWSECCLASS (Row Security Permission List). If one of these fields is on the search record as a Key, not a List Box Item, PeopleTools does the following. PeopleTools adds a WHERE clause when it performing a SELECT through the record forcing the value to be equal to the current user's value.