|Read more about this book|
(For more resources on Oracle, see here.)
Understanding User security
Before we get into discussing the PeopleSoft security, let's spend some time trying to set the context for user security.
Whenever we think of a complex system like PeopleSoft Financial applications with potentially hundreds of users, the following are but a few questions that face us:
- Should a user working in billing group have access to transactions, such as vouchers and payments, in Accounts Payable?
- Should a user who is a part of North America business unit have access to the data belonging to the Europe business unit?
- Should a user whose job involves entering vouchers be able to approve and pay them as well?
- Should a data entry clerk be able to view departmental budgets for the organization?
These questions barely scratch the surface of the complex security considerations of an organization. Of course, there is no right or wrong answer for such questions, as every organization has its own unique security policies.
What is more important is the fact that we need a mechanism that can segregate the access to system features. We need to enforce appropriate controls to ensure users can access only the features they need.
Global Vehicles' Accounts Payable department has three different types of users – Mary, who is the AP manager; Amy, who is the AP Supervisor; and Anton, who is the AP Clerk. These three types of users need to have the following access to PeopleSoft features:
|User type||Access to feature||Description|
|AP Clerk||Voucher entry||A clerk should be able to access system pages to enter vouchers from various vendors.|
|AP Supervisor||Voucher entry
|A supervisor also needs to have access to enter vouchers. He/she should review and approve each voucher entered by the clerk. Also, the supervisor should be able to execute the Voucher Post process that creates accounting entries for vouchers.|
|AP Manager||Pay cycle
|AP manager should be the only one who can execute the Pay Cycle (a process that prints checks to issue payments to vendors). Manager (in addition to the Supervisor) should also have the authority to approve vouchers.|
Note that this is an extremely simplified scenario that does not really include all the required features in Accounts Payable.
We will design a security matrix that uses distinct security roles. We'll configure permission lists, roles, and user profiles to limit user access to required system features.
PeopleSoft security matrix is a three-level structure consisting of Permission lists (at the bottom), Roles (in the middle) and User profiles (at the top). The following illustration shows how it is structured:
We need to create a User Profile for each user of the system. This user profile can have as many Roles as needed. For example, a user can have roles of Billing Supervisor and Accounts Receivable Payment Processor, if he/she approves customer invoices as well as processes customer payments. Thus, the number of roles that a user should be granted depends entirely on his/her job responsibilities.
Each role can have multiple permission lists. A Permission list determines which features can be accessed by a Role. We can specify which pages can be accessed, the mode in which they can be accessed (read only/add/update) in a permission list.
In a nutshell, we can think of a Role as a grouping of system features that a user needs to access, while a Permission list defines the nature of access to those system features.
Deciding how many and which roles should be created needs quite a bit of thinking about. How easy will it be to maintain them in future? Think of the scenarios where a function needs to be removed from a role and added to another. How easy would it be to do so? As a rule of thumb, you should map system features to roles in such a way that they are non-overlapping. Similarly, map system pages to permission lists so that they are mutually exclusive. This simplifies user security maintenance to a large extent. Note that although it is advisable, it may not always be possible. Organizational requirements are sometimes too complicated to achieve this. However, a PeopleSoft professional should try to build a modular security design to the extent possible.
Now, let's try to design our security matrix for the hypothetical scenario presented previously and test our thumb rule of mutually exclusive roles and permission lists.
What do you observe as far as required system features for a role are concerned? You are absolutely right if you thought that some of system features (such as Voucher entry) are common across roles.
Which roles should we design for this situation? Going by the principle of mutually exclusive roles, we can map system features to the permission lists (and in turn roles) without overlapping them. We'll denote our roles by the prefix 'RL' and permission lists by the prefix 'PL'. Thus, the mapping may look something like this:
|Role||Permission list||System feature|
So, now we have created the required roles and permission lists, and attached appropriate permission lists to each of the roles. In this example, due to the simple scenario, each role has only a single permission list assigned to it.
Now as the final step, we'll assign appropriate roles to each user's User profile.
|User||Role||System feature accessed|
Now, as you can see, each user has access to the appropriate system feature through the roles and in turn, permission lists attached to their user profiles.
Can you think of the advantage of our approach? Let's say that a few months down the line, it is decided that Mary (AP Manager) should be the only one approving vouchers, while Amy (AP Supervisor) should also have the ability to execute pay cycles and issue payments to vendors. How can we accommodate this change? It's quite simple really – we'll remove the role RL_Voucher_Approval from Amy's user profile and add the role RL_Pay_Cycle to her profile. So now the security matrix will look like this:
|User||Role||System feature accessed|
Thus, security maintenance becomes less cumbersome when we design roles and permission lists with non-overlapping system features. Of course, this comes with a downside as well. This approach results in a large number of roles and permission lists, thereby increasing the initial configuration effort.
The solution that we actually design for an organization needs to balance these two objectives.
Having too many permission lists assigned to a User Profile can adversely affect the system performance. PeopleSoft recommends 10-20 permission lists per user.
Configuring permission lists
Follow this navigation to configure permission lists:
PeopleTools | Security | Permissions & Roles | Permission Lists
The following screenshot shows the General tab of the Permission List set up page. We can specify the permission list description on this tab.
We'll go through some of the important configuration activities for the Voucher Entry permission list discussed previously.
- Can Start Application Server?: Selecting this field enables a user with this permission list to start PeopleSoft application servers (all batch processes are executed on this server). A typical system user does not need this option.
- Allow Password to be Emailed?: Selecting this field enables users to receive forgotten passwords through e-mail. Leave the field unchecked to prevent unencrypted passwords from being sent in e-mails.
- Time-out Minutes – Never Time-out and Specific Time-out: These fields determine the number of minutes of inactivity after which the system automatically logs out the user with this permission list.
The following screenshot shows the Pages tab of the permission list page. This is the most important place where we specify the menus, components, and ultimately the pages that a user can access.
In PeopleSoft parlance, a component means collection of pages that are related to each other. In the previous screenshot, you are looking at a page. You can also see other related pages used to configure permission lists – General, PeopleTools, Process, and so on. All these pages constitute a component. A menu is a collection of various components. It is typically related to a system feature, such as 'Enter Voucher Information' as you can see in the screenshot.
Thus, to grant a page access, we need to enter its component and menu details.
In order to find out the component and menu for a page, press CTRL+J when it is open in the internet browser.
- Menu Name: This is where we need to specify all the menus to which a user needs to have access. Note that a permission list can grant access to multiple menus, but our simple example includes only one system feature (Voucher entry) and in turn, only one menu. Click the + button to add and select more menus.
- Edit Component hyperlink: Once we select a menu, we need to specify which components under it should be accessed by the permission list.
Click the Edit Components hyperlink to proceed. The system opens the Component Permissions page, as shown in the following screenshot:
In this page, the system shows all components under the selected menu. The previous screenshot shows only a part of the component list under the 'Enter Voucher Information' menu.
Voucher entry pages for which we need to grant access exist under a component named VCHR_EXPRESS.
Click the Edit Pages hyperlink to grant access to specific pages under a given component. The system opens the Page Permissions page, as shown in the following screenshot:
The given screenshot shows the partial list of pages under the Voucher Entry component.
- Panel Item Name: This field shows the page name to which access is to be granted.
- Authorized?: In order to enable a user to access a page, select this checkbox. As you can see, we have authorized this permission list to access six pages in this component.
- Display Only: Clicking this checkbox allows the user to get read-only access for the given page. He/she cannot make any changes to the data on this page.
- Add: Selecting this checkbox enables the user to add a new transaction (in this case new vouchers).
- Update/Display: Selecting this checkbox enables the user to retrieve the current effective dated row. He/she can also add future effective dated rows in addition to modifying them.
- Update/Display All: This option gives the user all of the privileges of the Update/Display option. In addition he/she can retrieve past effective dated rows as well.
- Correction: This option enables the user to perform all the possible operations; that is, to retrieve, modify or add past, current, and future effective dated rows.
Effective dates are usually relevant for master data set ups. It drives when a particular value comes into effect. A vendor may be set up with effective date of 1/1/2001, so thatit comes into effect from that date. Now assume that its name is slated to change on 1/1/2012. However, we can add a new vendor row with the new name and the appropriate effective date. The system automatically starts using the new name from 1/1/2012. Note that there can be multiple future effective dated rows, but only one current row.
The next tab PeopleTools contains configuration options that are more relevant for technical developers. As we are concentrating on business users of the system, we'll not discuss them.
Click the Process tab. As shown in the following screenshot, this tab is used to configure options for Process groups.
A process group is a collection of batch processes belonging to a specific internal department or a business process. For example, PeopleSoft delivers a process group ARALL that includes all Accounts Receivable batch processes. PeopleSoft delivers various pre-configured process groups; however, we can create our own process groups depending on the organization's requirements.
Click the Process Group Permissions hyperlink. The system opens a new page where we can select as many process groups as needed. When a process group is selected for a permission list, it enables the users to execute batch and online processes that are part of it.
The following screenshot shows the Sign-on Times tab. This tab controls the time spans when a user with this permission list can sign-on to the system. We can enforce specific days or specific time spans for a particular day when users can sign-on.
In the case of our permission list, there are no such limits and users with this permission list will be able to sign-on anytime on all days of the week.
The next tab on this page is the Component Interface. The component interface is a PeopleSoft utility that automates bulk data entry into PeopleSoft pages. We can select component interface values on this tab, so that users with this permission list have access rights to use them.
Due to the highly technical nature of the activities involved, we will not discuss the Web Libraries, Web Services, Mass change, Links, and Audit tabs.
Oracle offers exhaustive documentation on PeopleSoft applications at the following URL: http://www.oracle.com/pls/psft/homepage. Documentation for technical topics such as web services can be found under the 'PeopleTools' section. Documentation for functional modules, such as Billing, Accounts Receivable, and so on, can be found under the Financials Supply Chain Management (FSCM) section.
The next important tab on the permission list page is Query. On this tab, the system shows two hyperlinks: Access Group Permissions and Query Profile.
Click the Access Group Permissions hyperlink. The system opens the Permission List Access Groups page, as shown in the next screenshot. This page controls which database tables can be accessed by users to create database queries, using a PeopleSoft tool called Query Manager.
- Tree Name: A tree is a hierarchical structure of database tables. As shown in the screenshot, the tree QUERY_TREE_AP groups all AP tables.
- Access Group: Each tree has multiple nodes called access groups. These access groups are just logical groups of tables within a tree. In the screenshot, VOUCHERS is a group of voucher-related tables within the AP table tree. With this configuration, users will be able to create database queries on voucher tables in AP.
Using the Query Profile hyperlink, we can set various options that control how users can create queries (such as if he/she can use joins, unions, and so on in queries, how many database rows can be fetched by the query, if the user can copy the query output to Microsoft Excel, and so on).
|Read more about this book|
(For more resources on Oracle, see here.)
Before we proceed, recall that a role can have multiple permission lists, while multiple roles can be granted to a user profile. Thus, a security role connects a user profile with actual page level access details, which are defined using permission lists.
Follow this navigation to set up security roles:
PeopleTools | Security | Permission & Roles | Roles
The following screenshot shows the General tab of role set up page, where we specify the role name.
Click the Permission Lists tab to attach the required permission lists to this role. The following screenshot shows the Permission Lists tab.
We will attach the permission list that we set up for voucher entry access to the role.
Click the View Definition hyperlink to open the permission list page and see details of the selected permission list. Add as many permission lists as required by clicking the + button.
The next two tabs (Members and Dynamic Members) show the details of static and dynamic members respectively. Let's first try to understand what that means.
We mentioned earlier that roles need to be assigned to user profiles to establish a link between profiles and permission lists. If this assignment of roles to profiles is done manually through PeopleSoft pages, selected users are known as static role members. This approach is fine with a small to medium user base, but what happens when the user base runs into thousands? Assigning various roles to all these users manually becomes a huge task. For such scenarios, we can programmatically assign roles to users based on predefined rules. In this case, the users are known as dynamic role members.
Click the Members tab to see if there are any static role users for this role. The following screenshot shows details of the Members tab.
For our illustrative example, let's assume that we manually assigned the RL_VOUCHER_ENTRY role to Anton. As a result, Anton comes up as a static role member in the Members tab.
Click the Dynamic Members tab to view how rules can be defined to programmatically assign this role to a large number of users. The following screenshot shows the Dynamic Members tab.
As you can see, there are three ways in which we can define the rule: using PeopleSoft Query, where a database query specifies criteria for the users who need to be assigned this rule, writing code in PeopleCode (this is the programming language used by PeopleSoft), or using the Lightweight Directory Access Protocol (LDAP) directory.
- Query Rule Enabled: Select this option if we specify the target user base through PeopleSoft query. This option enables a field where we can specify the query name.
- PeopleCode Rule Enabled: Select this option if the criteria for selecting the target user group is coded programmatically in PeopleCode. This option enables fields to specify the PeopleSoft record (table) name, field name, field event name, and name of the function that contains the required code.
- Directory Rule Enabled: Select this option if the criteria for selecting target user group is defined through a LDAP directory rule. This option enables the Assign Directory Rule hyperlink, allowing us to specify the appropriate rule.
We'll limit our discussion of security roles to these basic tabs.
Configuring user profiles
Each user that needs to access the PeopleSoft system requires a user profile. As you already know, a user profile needs to be assigned the required roles to enable that user to access certain system features.
Follow this navigation to set up user profiles:
PeopleTools | Security | User Profiles | User Profiles
The following screenshot shows the General tab of the User Profile page.
Access to this page is highly restricted and usually limited to the system administrator function.
- Account Locked Out?: If this checkbox is selected, the user cannot sign in to the system. Thus, it is important to have it unchecked to allow a user to access the system.
- Password and Confirm Password: Specify the password for this user to log in to the system.
- Primary, Row Security: Assign a permission list for the row-level security to control the actual values of key fields (such as BU, SetID, and so on).
Click the ID tab to specify the type of system user (such as Employee, Customer, Vendor and so on) and specify relevant attributes (such as Employee ID, Customer ID, Vendor ID, respectively) as shown in the following screenshot:
Click the Roles tab to assign security roles to the user. As we discussed earlier, this will mean that the user is a static role member. The next screenshot shows the Roles tab.
We'll assign the RL_VOUCHER_ENTRY role we configured earlier to this user profile. This will enable Anton to access necessary voucher entry pages through the PL_VOUCHER_ENTRY permission list.
- Dynamic: If dynamic role assignment is used for this role, this checkbox is automatically selected.
- Dynamic Role Rule: We already discussed that role assignment rules can be defined while setting up security roles. Options in this section help in testing the assignment and execution.
- Test Rule(s): When this button is clicked, the system generates a report that shows which dynamically-defined roles will be assigned to this user in addition to the manually-assigned rules. Remember that this is just a preview for the role assignment and the roles will not be really assigned.
- Execute Rule(s): Click this button to run the dynamic role assignment process.
Click the Workflow tab to set up workflow configuration options for this user, as shown in the following screenshot:
- Alternate User ID, From Date, To Date: Specify an alternate user ID, who should receive all workflow items that the original user receives, between the dates specified in the From Date and To Date fields. This feature is useful when a user is temporarily away due to a vacation or similar occasions. In the given example, all workflow notifications for Anton will be routed to the user ID TKENDALL between 1st and 21st October, 2011.
Note that assignment of workflow items is applicable only for new items. Any items that were already assigned to the user are not reassigned.
- Total Pending Worklist Entries: This field shows the workflow items that are currently assigned to the user and are not completed.
- Reassign Work To: This option enables reassignment of currently assigned pending items to a different user.
Understanding Row-level security
So far we have discussed security access being controlled using permission lists and roles to specify which application pages can be accessed by users.
In addition to the page security, PeopleSoft offers another level of security called Row level security. This method is useful to control access to specific rows of data using either specific User IDs or permission lists.
To understand this concept, let's continue our example of Anton, who can enter vouchers in the Accounts Payable module. We already saw configuration options that allowed us to limit his system access to voucher entry pages. But can we restrict his access to vouchers for only one Business Unit, (BU) say US001? We certainly did not see such options while configuring user profiles, roles, or permission lists. This is where row-level security comes in.
If we wish to limit Anton to seeing vouchers in the system for US001 BU alone, we essentially want to limit his access to only those database rows belonging to US001 BU.
Row-level security can be implemented for database rows that are controlled by the following fields:
- Business unit
- Ledger (and ledger group)
- Pay cycle
- Planning Instance
We just discussed how to control access to data with a specific Business Unit. If needed, we can limit user access to data for a specific SetID, Ledger or any of the fields in the given list.
Note that even if we decide to use row-level security, it is not mandatory to use all the fields mentioned previously for access control. For example, we may wish to use row-level security for only business unit and SetID, while users are free to access data for any pay cycle, ledger, and so on.
There are two ways of configuring row-level security:
- User ID level security
- Permission list level security
User ID level security
In this method, we need to specify which values of Business Unit, SetID, and so on, can be accessed for each user. Thus, a sample configuration may look like this, assuming we have enabled row level security only for Business Unit and SetID fields:
|User ID||Business Unit access||SetID access|
This approach works well if the user base is small. As you can imagine, configuring it for a large user base running in the thousands is not practical. This is where we need to use the permission list level security.
Permission list level security
In this method of row-level security, key field values are assigned to a permission list rather than an individual user ID. This permission list is assigned to multiple users as the Primary Permission List (recall the General tab on the User Profile page).
Assuming that there are 500 users who need to access data for BUs US001 and FRA01 and SetID GLOVH, we can use the following configuration:
|Business Unit access||SetID access|
Later, this permission list is assigned to all the users as primary permission list.
Now let's say that all these users need to access an additional BU GBR01, we need to do it only for the given mapping and it will be reflected for all the 500 users.
Specifying Row-level security options
Follow this navigation to specify system security options:
Setup Financials/Supply Chain | Security | Security Options | Security Options
The following screenshot shows the Security Options page where we can specify the security type and the important fields for which access needs to be restricted.
- No Security: If this option is selected, users can access data belonging to all business units, ledgers, or any other key field.
- User ID Level Security: This enables security by individual User ID. We need to assign permissible values to user ID profiles on other pages.
- Permission List Level Security: This enables security by Permission List. We need to assign permissible values to permission lists on other pages.
- Secured Fields: As you can see, the system shows the key fields listed previously. We need to select the fields that we need for row-level security access. Based on the fields we select, we need to assign permissible values to appropriate User ID or Permission list.
In the example shown in the previous screenshot, we have enabled row level security for Business Unit and selected Permission level security. Therefore, we'll have to assign the BU values to be accessed to the appropriate permission list. We'll see how to do it a little later.
Applying security options
The security options that we specified previously do not come into effect, unless we execute the Apply Security Setups batch process.
Follow this navigation to apply security options:
Setup Financials/Supply Chain | Security | Apply Security Setups
The following screenshot shows this page. Note that this process does not need any input parameters.
Click the Run button to execute the process.
Defining Row-level security values
As we discussed previously, we need to assign the values for the enabled fields to appropriate User ID or Permission lists.
PeopleSoft provides the following 10 pages to assign various key field values to User IDs or Permission lists:
- Unit Security by Permission List
- Unit Security by User ID
- TableSet Security by Permission List
- TableSet Security by User ID
- Ledger Security by Permission List
- Ledger Security by User ID
- nVision Ledger Security
- Pay Cycle by user ID
- Pay Cycle by Permission list
- Project Security
We'll discuss only the Unit Security pages, as most of the other pages are similar.
Unit Security by Permission List
Follow this navigation to assign BU values to a permission list:
Setup Financials/Supply Chain | Security | Unit by Permission List
The following screenshot shows the Business Unit Security by Permission List page.
In this example, BU values US001, FRA01 and GBR01 are assigned to a permission list ALLPAGES. Any user with this permission list as the primary permission list on his/her user profile will be able to access data for only for these BU values.
Unit Security by User ID
Follow this navigation to assign BU values to an individual User ID:
Setup Financials/Supply Chain | Security | Unit by User ID
The following screenshot shows the Business Unit Security by User ID page.
In this example, BU values US001 and FRA01 are assigned to a user ID AJAMES. This user will be able to access data only for these two BU values.
PeopleSoft security performs a critical task of controlling the access of system features to appropriate users. User security is a three-level hierarchical structure consisting of User Profiles, Roles, and Permission Lists. Permission Lists control which pages can be accessed and the mode of the access. A Role is assigned as many permission lists as needed. It can be considered a collection of system features. A user profile is created for each system user and is assigned as many roles as needed by the user.
While the user security controls which system pages can be accessed by a user, the Row-Level Security controls which rows of data can be accessed by a user. It limits the data retrieved by a user to specific values of a Business unit, SetID, Ledger, Book, Project, Pay cycle, or a Planning Instance. Row-level security options can be implemented by User ID (suited to a small user base) or Permission List (ideally suited for large user base with similar access requirements). In other words, we can specify which values of the given key fields can be accessed either for a user ID or a permission list.
- Oracle WebCenter 11g: Portlets [Article]
- An Overview of Oracle Advanced Pricing [Article]
- An Overview of Oracle PeopleSoft Commitment Control [Article]
- Oracle Business Intelligence: Drilling Data Up and Down [Article]
- Integrating Discussions, Wiki, and Blog with Oracle WebCenter [Article]