Setting Up Permission Lists

This chapter provides an overview of permission lists and discusses how to:

Manage permission lists.
Define permissions.

Understanding Permission Lists

Permission lists are the building blocks of user security authorizations. You typically create permission lists before you create user profiles and roles. When defining permission lists, however, consider the roles and user profiles with which you will use them. Recall that roles are intermediary objects between permission lists and users. You use roles to assign permissions to users dynamically.

Permission lists may contain any number of permissions, such as sign-in times, page permissions, web services permissions, and so on. Permission lists are more flexible and scalable when they contain fewer permissions.

The following diagram illustrates how permission lists are assigned to roles, which are then assigned to user profiles. A role may contain numerous permissions, and a user profile may have numerous roles assigned to it. A user inherits all permissions assigned to each role to which the user belongs. User access is determined by the combination of all assigned roles.

Security definition hierarchy

The diagram represents the security authorizations of Tom Sawyer. Mr. Sawyer inherits the five permission lists that are assigned to the two roles that are assigned to his user profile. In this example, he has access to the employee self-service pages, the service monitor, PeopleSoft Process Monitor, and PeopleTools Security. If Tom were to become a manager, then the permission lists assigned to the Manager role would be added to his profile.

Theoretically, you could create a permission list tailored for every role, and that permission list could contain a permission for every category, from General to Web Libraries. However, permission lists like this do not scale to encompass roles that might be similar, but not exactly alike. For a similar role, you'd have to create a new role from the beginning. This kind of approach is not efficient for larger, more complicated implementations.

Alternatively, you can use a more modular, or mix-and-match, approach where you create numerous, generic permission lists that you can add to and remove from role definitions. Suppose you have three 8-hour shifts at your site. Using the modular approach, you could create three different versions of sign-in permissions: one for 6 a.m. to 2 p.m., one for 2 p.m. to 10 p.m., and another for 10 p.m. to 6 a.m. Then, depending on the shift for a particular role, you can easily apply or remove the appropriate permission as needed without affecting any other permissions.

Although how you decide to implement Permission Lists depends on your site's security scheme and your security administrator, the modular approach provides increased scalability. As a general rule, your permission lists should be assigned to roles so that the common user has between 10 to 20 lists. This range represents the best balance of performance and flexibility. If you have too many permission lists, you may notice performance degradation, and if you have too few permission lists, you may sacrifice flexibility.

Managing Permission Lists

This section discusses how to:

Create new permission lists.
Copy permission lists.
Delete permission lists.
View related content references.
Add links.
Run permission list queries.

Creating New Permission Lists

To create a new permission list:

Select PeopleTools, Security, Permissions & Roles, Permission Lists.
On the search page, click Add a New Value.
In the Permission List edit box, enter the name of permission list to create.

Note. Permission list names have a 30-character limit. PeopleSoft HCM requires certain naming conventions for permission lists, but PeopleTools does not enforce these application-specific requirements. Therefore, when creating permission lists, keep in mind that PeopleSoft HCM requires primary permission lists to start with PP, and data permission lists to start with DP.
From the pages in the Permission List component, select the appropriate permissions.
Save your permission list.

Copying Permission Lists

To copy a permission list:

Select PeopleTools, Security, Permissions & Roles, Copy Permission Lists.
On the search page, locate and select the permission list that you want to copy (clone).

The Permission List Save As page appears.
On the Permission List Save As page, enter a new name in the To: edit box for the permission list that you want to copy.
Click Save.

Note. When copying a permission list, you also copy the access specified for content references by the original permission list. When deleting a permission list, you also remove access to the content references associated with that permission list.

Deleting Permission Lists

To delete a permission list:

Select PeopleTools, Security, Permissions & Roles, Delete Permission Lists.
On the search page, locate and select the permission list that you want to delete.

The Delete Permission List page appears.
Click Delete Permission List.
Click OK to confirm the deletion, or click Cancel to end without deleting.

Note. This deletes content reference permissions and all references to the permission list (even where referenced in application data).

Viewing Related Content References

This section discusses:

Viewing content references.
Synchronizing content references.

Viewing Content References

Select PeopleTools, Security, Permissions & Roles, Permission Lists, Pages to access the Pages page, then click the Edit Components link to access the Component Permissions page.

See Setting Page Permissions.

When you set component permissions and web library permissions, use the View Content References link to view the content references pointing to a given component or script. PeopleTools automatically propagates changes to permission lists to the content references.

When you click the link, the Content References page appears, showing the following:

Name of the portal.
Name of the content reference.
The label.
Whether or not it is accessible.
The path.

Synchronizing Permission Lists and Content References

Use the PORTAL_CSS application engine program to synchronize permission lists with content references for the portal. By default, the system synchronizes changes in permission lists with content references; however, after an upgrade or any time when you want to make sure, you can run the PORTAL_CSS program. There is a process definition of the same name.

See Administering Content References.

Adding Links

Select PeopleTools, Security, Permissions & Roles, Permission Lists, Links to access the Links page.

Use this page to add links to other pages within your PeopleSoft system that pertain to a particular permission list. For example, perhaps a PeopleSoft application requires a specific security setting to be attached to a permission list. If this application-specific setting appears on a page not in PeopleTools, Security, add a link to that page so that anyone updating the permission list can easily navigate to it.

You create your inventory of links to security settings that exist outside of PeopleTools Security using the Security Links page. After being created and assigned to a security definition, such as a permission list, then the links appear in the security definition's list of links.

Running Permission List Queries

Select PeopleTools, Security, Permissions & Roles, Permission Lists, Permission List Queries to access the Permission List Queries page.

Permission list queries enable you to run queries that provide detailed information regarding a permission, such as the user IDs and roles associated with a permission list. The available queries are documented on the page.

To run a permission list query:

Click the link associated with the query you want to run.

This invokes a new browser window.
View the information the query returns, or select a download option.

For downloading, you have the following options:
- Microsoft Excel spreadsheet.
  
  Downloads the query results as a Microsoft Excel spreadsheet (.xls) file.
- CSV text file.
  
  Downloads the query results as a comma-separated values (.csv) file.

Defining Permissions

This section discusses how to:

Set general permissions.
Set page permissions.
Set PeopleTools permissions.
Set process permissions.
Set sign-in time permissions.
Set component interface permissions.
Set service monitor permissions.
Set web library permissions.
Set personalization permissions.
Set query permissions.
Set mass change permissions.
View when a permission list was last updated.

Pages Used to Define Permission Lists

Page Name	Object Name	Navigation	Usage
General	ACL_GENERAL	PeopleTools, Security, Permissions and Roles, Permission Lists, General	Set general or miscellaneous attributes and system defaults.
Pages	ACL_MENU2	PeopleTools, Security, Permissions and Roles, Permission Lists, Pages	Set page permissions.
PeopleTools	ACL_MISCTOOLS	PeopleTools, Security, Permissions and Roles, Permission Lists, PeopleTools	Grant access to PeopleTools applications, such as PeopleSoft Application Designer, and grant access for specific operations within PeopleTools.
Process	ACL_PROCESS	PeopleTools, Security, Permissions and Roles, Permission Lists, Process	Specify to what capacity a user or role can modify PeopleSoft Process Scheduler settings.
Sign-on Times	ACL_SIGNON2	PeopleTools, Security, Permissions and Roles, Permission Lists, Sign-on Times	Specify when users are authorized to sign in to the PeopleSoft system. If users are signed in to the system when the sign-in time expires, they are automatically signed out.
Component Interface	ACL_COMP_INTERFACE	PeopleTools, Security, Permissions and Roles, Permission Lists, Component Interface	Grant access to any component interfaces that a user may need to use to complete business transactions.
Web Libraries	ACL_WEBLIBS	PeopleTools, Security, Permissions and Roles, Permission Lists, Web Libraries	Set web library permissions.
Web Services	ACL_WS_OPR	PeopleTools, Security, Permissions and Roles, Permission Lists, Web Services	Set web services permissions.
Personalizations	PLIST_OPTN	PeopleTools, Security, Permissions and Roles, Permission Lists, Personalizations	Specify which personalizations users can use and customize.
Query	PERMLIST_QUERY	PeopleTools, Security, Permissions and Roles, Permission Lists, Query	Control the query operations a user can perform and the data a user can access while using PeopleSoft Query.
Mass Change Operator Security	MC_OPR_SECURITY	PeopleTools, Security, Mass Change Operator Security	Set mass change security permissions.
Audit	PERMLIST_AUDIT	PeopleTools, Security, Permissions and Roles, Permission Lists, Audit	Inquire when a permission list was last updated and by whom.

Setting General Permissions

Access the Permission Lists - General page.

Navigator Homepage

Select a graphic representation of a business process that is displayed by PeopleSoft Navigator. For each security profile definition, you can specify a map to be displayed on startup.

If this is the user profile's PeopleSoft Navigator homepage permission list, the system is passed this value at runtime.

Can Start Application Server?

Select to enable user profiles with this permission list to start PeopleSoft application servers.

Note. This setting also applies to starting PeopleSoft Process Scheduler servers.

Typically, you'll create a user profile that's dedicated to starting application servers. When you define an application server domain, one of the parameters you specify in PSADMIN is the PeopleSoft user ID (and password) for that profile, which must be associated with at least one permission list that has this option enabled. The user ID and password are stored in the Startup section of the PSAPPSRV.CFG file, which BEA Tuxedo reads when the application server is started.

In many installations, an application server starts with an automated process. A user profile with this property enabled shouldn't be used by an actual user who signs in to the application server and starts it by submitting the appropriate commands.

Note. Password controls don't apply when a password is used for two-tier activities like starting application servers. They apply only when the password is used to sign in over three-tier connections.

Important! For a given user profile, the password controls that you set for account lockout (maximum logon attempts) and age (expiration) apply to three-tier and web sign-in only, and don't apply if the user profile is used just for two-tier activities like starting an application server or process scheduler.

However, make sure that you don't use the same user profile for both types of activities. When you use it for both three-tier and web sign-in, the profile becomes subject to the account lockout and age controls, which prevents it from completing the two-tier activities.

Allow Password to be Emailed?

Select to enableusers to receive forgotten passwords through email. At some sites, the security administrator may not want passwords appearing unencrypted in any email. You implement this feature by permission list. None can use it, some can use it, or all can use it depending upon your implementation. Users who do not have the proper authority receive an error message if they attempt to have a new password emailed to them.

Never Time-Out and Specific Time-out (minutes)

Select the number of minutes of inactivity allowed at a terminal before the system automatically signs the user out of the PeopleSoft online system. Inactivity means no mouse clicks, keystrokes, import, file print, or SQL activity. The default time-out minutes setting is Never Time-out.

Note. Time out limits are also controlled at the web server and application server levels.

If you select Never Time-out, an inactive user is never automatically signed out. Otherwise, select Specific Time-out (minutes) and enter the appropriate value in minutes. A custom time-out interval:

Must be a positive integer.

Can't contain edit characters, such as commas or a $.

Must be a SMALLINT in the valid range allowed for this field (0-32767).

Entering a value of zero (0) is equivalent to selecting Never Time-out.

To comply with the Americans with Disabilities Act (ADA), you might set up most permission lists to time out in 20 minutes, but create a special ADA permission list where timeout occurs after 60 minutes.

Note. Because timeout limits are also controlled at the web server level, you'll need to change the web server timeout values also.

Setting Page Permissions

Access the Permission Lists - Pages page.

Mobile Page Permissions

Click to grant access to mobile application pages.

Menu Name

Displays all menu names in the database. Add new rows to add more menu names. The name reflects the definition name in PeopleSoft Application Designer.

Menu Label

Displays the menu label associated with the PeopleSoft Application Designer menu name.

Edit Components

Click to grant access to specific pages.

Page permissions refer to the pages to which a user has access. Pages are contained within components, which are ultimately contained within a menu name. To grant access to a particular page, determine the component it is in and the menu name the component falls under. This enables you to drill down to the appropriate page.

Note. To find the name of a page, you can press Ctrl+J while accessing the page with the browser, or use the Find Definition References feature in PeopleSoft Application Designer.

Granting access to PeopleTools and PeopleSoft applications requires serious considerations. For each role, carefully consider what the members of that role must access to complete their jobs and to what degree they need access. Then make the appropriate permission lists.

After you add a menu name, you grant access to its components and pages on an item-by-item basis. In PeopleSoft applications, menu items represent components. If a component consists of more than one page, then selecting the menu item opens another layer with more items—individual pages. For example, if you added the UTILITIES menu name to a permission list, you could then grant access to the Utilities, Use menu items but not to the Utilities, Process menu items. Or you could grant access to only a few of the Use menu items, or make some items display only.

There are two categories of components to which you grant access permission:

All PeopleSoft applications.
Page-driven PeopleTools.

Note. With PeopleTools programs, the process of editing menu items varies. With page-based PeopleTools, such as PeopleSoft Process Scheduler, you can grant access to menu items just as you can for PeopleSoft applications. However, the other PeopleTools programs don’t allow you to grant item-by-item access; you can either access all the menus and menu items or you can’t. PeopleSoft Application Designer is an exception; you can restrict access to it at the definition level.

Granting Access to Components and Pages

The following procedure describes how to set access permissions to your PeopleSoft applications and your page-driven PeopleTools. You begin at the component level and drill down to the page level making the appropriate selections as you go.

Note. The same procedure applies to both PeopleSoft applications and page-driven PeopleTools.

To add access to PeopleSoft components and pages:

Locate the menu name of the component to which you want to add access.
Click Edit Components.

The Components page appears.
Locate the component to which you want to grant access.

By default, when adding a new permission list, no components are authorized.
Click the Edit Pages button associated with each component to which you want to grant access.

The Page Permissions page appears. You specify the actions that a user can complete on the page. You have the following options for each page that appears in the Page column:
- Authorized?
  
  Select to enable a user to access the page. Decide the degree to which a user is authorized on a page by selecting Display Only or one or more of the available options in the Actions group.
- Display Only.
  
  Select to enable the user to view the information provided by the page, but not to alter any data.
- Actions.
  
  Specify how users can alter information on a page, such as Add, Update/Display, and Correction. The available options depend upon the options selected when the page was initially developed in PeopleSoft Application Designer.
  
  To grant access to all pages and all actions for each page, click Select All.
When you have finished making the appropriate selections, click OK on the Page Permissions page, and then again on the Component Permissions page.

Repeat each step for each menu name.

Note. After you delete access to a component or iScript, you must clear the browser cache or wait for 20 minutes (default time) for the deletion to appear on the menu.

Granting Access to Mobile Pages

To add access to mobile pages:

Select PeopleTools, Security, Permissions & Roles, Permission Lists, and select the Pages page.
Click the Mobile Page Permissions link.

The Mobile Page Permissions page appears.
To add a new mobile page to the permission list, click the plus sign.
For the Mobile Page Name edit box, click the search button.
Search for and select the mobile page for which you need to grant access.
Click OK.
Save the permission list.

Setting PeopleTools Permissions

Access the Permission Lists - PeopleTools page.

The PeopleTools Permissions section of this page applies to standalone PeopleTools applications. They aren't Pure Internet Architecture-based, but are Microsoft Windows programs that weren't developed using PeopleSoft Application Designer. They include:

PeopleSoft Application Designer.
PeopleSoft Data Mover.
PeopleSoft Definition Security.
PeopleSoft Query (Microsoft Windows interface, not the browser interface).

The Performance Monitor PPMI Access check box doesn't control access to an application; rather, it enables PeopleSoft Performance Monitor data collators to insert performance data into the database, which enables you to view the data.

See Enterprise PeopleTools 8.49 PeopleBook: PeopleSoft Performance Monitor.

To grant access to these PeopleTools features, select the check box next to the appropriate item.

With PeopleSoft Application Designer, the procedure for applying permissions is slightly more complex, because security for PeopleSoft Application Designer also controls what object definition types can be accessed and what degree of modifications can be made. The links on this page (Definition Permissions, Tools Permissions, and Miscellaneous Permissions) enable you to provide more detail to PeopleSoft Application Designer access permissions.

Definition Permissions

Select Definition Permissions to access the Definition Permissions page.

Grant access to the definitions that developers create using PeopleSoft Application Designer. Each type of definition that you create with PeopleSoft Application Designer appears in the definition permissions list.

Note. On this page you add permissions to a definition type, such as Application Engine programs. You grant access to specific definitions, such as PeopleSoft Payroll Application Engine programs, using Definition Security.

Access

Select the appropriate access level. Options are:

Full Access: Definitions of the specified type can be modified. For records, this setting allows access to the Build dialog box.

No Access: No definitions of the specified type can be opened.

Read-Only: Definitions of the specified type can be opened and viewed but not modified.

Update translates only: This level applies only to fields. This allows a user to modify only Translate table values.

Data admin only: This level applies only to records. It allows a user to modify only those record attributes found in the Tools, Data Administration menu (tablespaces, indexes, and record DDL).

Full Access (ALL), Read Only (ALL) and No Access (ALL)

Click to set all definition types in the list to the same access level.

Note. If change control locking is enabled, the Change Control access setting on the Tools Permissions page can override object types settings.

See Building and Maintaining Data, Implementing Definition Security.

Tools Permissions

In addition to securing definitions, PeopleSoft Application Designer security also involves a collection of tools, such as Build and the PeopleCode Debugger, to which developers need access.

The tools within PeopleSoft Application Designer include the following:

Build/Data Admin (select Build, Project and Tools, Data Administration).
Change Control (select Tools, Change Control).
Language Translations (select Tools, Translations).
PeopleCode Debugger (select Debug, PeopleCode Debugger Mode).
SQL Editor (the PeopleSoft Application Designer utility for adding SQL objects and statements to applications and application engine programs).
Upgrade (select Tools, Upgrade).

This includes Copy Project, Compare and Report, and so on.

You can set the access level individually for the Tools Permissions page options or your can use the (ALL) buttons to set across the board settings. Remember that every button affects every access level for the tools.

Build/Data Admin	Control access to the Build and Tools, Data Administration menu items. Select from: No access. The user cannot access the Build menu items or the Tools, Data Administration menu items. Note. This setting is not available if you’ve set records access to No Access or to Data Admin only. Build scripts only. A user with this access level can use the Build dialog box options, but the Execute SQL now and Execute and build script options are disabled. The Tools, Data Administration menu items are not available. Note. This setting is not available if you’ve set records access to No Access. Build Online. With this access level, a user can use all Build dialog options, but the Tools, Data Administration menu items are not available Note. This setting is not available if you’ve set records access to No Access. Full data admin access. A user with this access level can use all the Build dialog options and access the Tools, Data Administration menu items. Note. This setting is not available if you’ve set records access to No Access or to Read-only access.
Change Control	The change control access levels are valid only when change control is enabled. You enable change control locking using PeopleSoft Application Designer. Select from: Restricted access. Restricts users from locking or unlocking objects. When change control locking is enabled, users with restricted access can only view PeopleSoft Application Designer definitions—they cannot create, modify, or delete them. Note. With locking enabled, this setting overrides any Full Access settings on the Object Permissions page or Miscellaneous Permissions page. Developer access. The user can lock any unlocked objects and unlock any objects that he or she has locked. Supervisor access. The user can unlock any locked objects, regardless of who has locked them.
Language Translations	Set only two levels of access, No access and Full access. Enable this set of menu options for people involved in translating or globalizing your applications.
PeopleCode Debugger	Restrict access to the PeopleCode Debugger.
SQL Editor	Restrict developers from modifying the SQL in your applications.
Upgrade	Select No access to make all the Upgrade menu items on the Tools menu unavailable. Developers can still access the Upgrade view and modify upgrade settings in the project definition, but they cannot run any the upgrade processes. With Read-only access, users can run compare reports against the database, but they cannot copy objects into the database.

The following table shows the relationship between the permissions that are set up within the source and the target databases, which you should consider in upgrade situations.

Source DB	Target DB	Compare?	Copy?	Export?	Import?
No access	No access	No	No	No	No
No access	Read-only access	No	No	No	No
No access	Full access	No	No	No	No
Read-only access	No access	No	No	Yes	No
Read-only access	Read-only access	Yes	No	Yes	No
Read-only access	Full access	Yes	Yes	Yes	No
Full access	No access	No	No	Yes	Yes
Full access	Read-only access	Yes	No	Yes	Yes
Full access	Full access	Yes	Yes	Yes	Yes

Miscellaneous Permissions

Set access levels for the Miscellaneous Definitions items that appear in the PeopleSoft Application Designer Tools menu, including Access Profiles, Color, Field Format, Style, and Tool Bar.

Each of the miscellaneous definitions can be set for No access, Read-only access, or Full access. You can select the (ALL) buttons to grant the same permissions to each item.

Realtime Event Notification Permissions

Select this link to access the REN Permissions (Realtime Event Notification Permissions) page.

See Configuring REN Server Security.

Data Archival

Use the PeopleSoft Data Archive Manager application to archive your data as part of regular database maintenance. The security options in this group relate specifically to actions a system administrator would make while using PeopleSoft Data Archive Manager. The actions that a system administrator can perform within PeopleSoft Data Archive Manager are controlled by permission lists. Before you grant any permissions to these actions, read the PeopleSoft Data Archive Manager documentation.

Note. PeopleSoft Data Archive Manager is a page-driven PeopleTools application, but on this page you enable specific operations used within the archiving process.

See Also

Using PeopleSoft Data Archive Manager

Setting Process Permissions

Just as you define permissions for the pages a user can access, it is also critical to specify the batch (and online) processes that users can invoke through PeopleSoft Process Scheduler. Typically, process groups are arranged by department or task. For example, the batch programs having to do with your payroll department probably all belong to the PAYROLL process group, or something similar.

When you create a process permission list, you add the appropriate process groups so that a user belonging to a particular role can invoke the proper batch programs to complete their business transactions. You do this using the Process Group Permission page.

You use the Process Profile Permission page to specify when a user or role can modify certain PeopleSoft Process Scheduler settings.

Note. The Process Profile is granted to the user by way of the user profile, and the Process Group is granted to the user by way of a permission list.

Process Group Permissions

Access the Process Groups page.

This page lists the process groups associated with a permission list. Process groups are collections of process definitions that you create using PeopleSoft Process Scheduler.

Typically, you group process definitions according to work groups within your organization, and typically that work group has a particular role associated with it. Regardless of how you organize process definitions, you must assign process groups to a permission list.

Users can run only the processes that belong to process groups assigned to their roles. For example, you may have a set of process definitions that relate to your Human Resources department and another set for your Manufacturing department.

Process Profile Permissions

Access the Process Profile Permission page.

Server Destinations

You can specify output variables when running processes or jobs on a server. You have the following options:

File.

If the output is going to a file, then specify the directory to which the file should be written. %%OutputDirectory%% is a meta-variable that resolves to the output directory that you’ve specified in PSADMIN (or PSPRCS.CFG) for the Process Scheduler Server Agent.

Printer.

Specify the network, or local, printer to which the hardcopy output should be sent. You must explicitly specify the printer; there are no meta-variables available for this value.

OS/390 Job Controls

Note. This group of options applies only to DB2 UDB for z/OS.

All PeopleSoft Process Scheduler shell JCLs use meta-strings to pass data stored in the database. PeopleSoft Process Scheduler takes advantage of meta-strings to generate the JCL job cards based on the user who initiated the request. For example, Job Name and Job Account can be passed by setting the Name and Account values, respectively, on the Process Profile page. For z/OS, you have the following options:

Job.

Enter %JOBNAME%.

Account.

Enter %JOBACCT%.

See your RDBMS documentation and the PeopleSoft installation guides for details about JCL meta-variables and strings.

Allow Process Request

These options apply to using PeopleSoft Process Monitor. You can restrict which users are permitted to view or update a given process, based on the user who launched (and owns) the process. You can specify restrictions as follows:

View by.

Specify who can view processes that are launched by users who have this permission list assigned as their process profile permission list on the User Profile - General page.

Select from the following options:

Owner: For a process that's launched by a user who has this process profile permission list assigned, only the user who launched the process can view it.

All: All users can view processes that are launched by a user who has this process profile permission list assigned.

None: No one can view processes that are launched by a user who has this process profile permission list assigned.

Update By.

Specify who can update the status of processes that are launched by users who have this permission list assigned as their process profile permission list on the User Profile - General page. For example, you decide whether users can restart or cancel a request.

Note. Updates are made using the PeopleSoft Process Monitor Process Detail page in the Update Process component.

Select from the following options:

Owner: For a process that's launched by a user who has this process profile permission list assigned, only the user who launched the process can update it.

For example, nobody else can restart a request that this user submitted. However, this user might still be able to update another user's processes.

All: All users can update processes that are launched by a user who has this process profile permission list assigned.

None: No one can update processes that are launched by a user who has this process profile permission list assigned.

Note. Be careful as you grant update authority to submitted processes. An inexperienced user can easily disrupt batch processing by deleting or holding processes. This is especially true with restarting processes. If a program is not coded for a restart, then users should not be able to restart it. Restarting a program that is not properly coded to acknowledge the previous program run can threaten data integrity. Remember, the process profile permissions are based on the profile of the user who is submitting the process, not the user viewing the process monitor.

The Allow Requestor To options apply to using PeopleSoft Process Monitor and PeopleSoft Process Scheduler Request pages. These options enable you to restrict the authority that a user has while monitoring scheduled processes.

Override Output Destination	Select to allow a user to change the value in the Output Destination column on the Process Scheduler Request page.
Override Server Parameters	Select to enable users to select the server name and modify the run date/time group on the Process Scheduler Request page.
View Server Status	Select to enable users to access the Server List page in PeopleSoft Process Monitor.
Update Server Status	Select to allow a user to suspend, restart, or bring down a server using the Server Detail page from the server list in PeopleSoft Process Monitor.
Enable Recurrence Selection	Select to enable a run recurrence value for processes and jobs scheduled to run on the server.

Setting Sign-in Time Permissions

Access the Permission Lists - Sign-on Times page.

Pick a day and set a sign-in duration.

Sign-in times use the 24-hour clock and run through the end time value. For example, a user with an end time of 16:30 can use the system until 4:31 p.m.

To create a sign-in time that spans multiple days, use adjoining sign-in times. For example, to create a sign-in time running from 8 p.m. Tuesday to 6 a.m. Wednesday, you need a Tuesday start time of 20:00 and end time of 23:59. Then you need to add a Wednesday sign-in time with a start time of 0:00 and an end time of 5:59.

By default, all start times are 0:00 and end times are 23:59, and all days are listed. Delete days and change the times to restrict access.

A single day can have more than one sign-in period as long as the periods don’t overlap. If there are multiple non-overlapping sign-in periods for one day, that day appears once for each period.

Setting Component Interface Permissions

Access the Permission Lists - Component Interfaces page.

Name

Shows the name of the component interface.

Edit

Click to access the Component Interface Permissions page and grant access to a particular component interface method.

You grant access to component interfaces similarly to adding page access. Add a new row to insert a component interface into the definition list. You must also grant access to the component interface methods.

After adding a new permission to a component, you must delete the web server cache for users to access the component through the portal. To delete the web server cache, reboot the web server.

Note. If more than one JVM services the web server, rebooting the web server only purges the in-memory cache. No procedure exists to specify which JVM receives the request. For this reason, you must reboot all JVMs that service the web server.

Setting Web Library Permissions

Access the Permission Lists - Web Libraries page.

A web library is a derived/work record whose name starts with WEBLIB_. All PeopleSoft iScripts are embedded in records of this type. An iScript is a specialized PeopleCode function that generates dynamic web content.

Administrators should make sure that users have the proper access to web libraries. For example, the default navigation system for PIA users is implemented using a web library. If users do not have the proper authorization to the web library and its associated scripts, then they won't have proper access to the system. If users are not authorized for a particular web library or script, then they can't invoke it.

After you add a web library, you set the access for each script function individually. Invoking an iScript requires the assembly of a URL. Developers assemble the URL using PeopleCode.

Web Library Name	Displays the web libraries added to the permission list.
Edit	Click to set access to web library functions. Select access rights for each function.

See Also

Using Internet Scripts

Setting Web Services Permissions

The web services offered by the PeopleSoft Integration Broker can be secured at the user ID level through the use of the web services permissions you specify. This applies to external web service requests only, not internal web service requests. Internal requests are those submitted from within your PeopleSoft system by a PeopleSoft user of one of your deployed PeopleSoft applications. External requests are those received from third party systems, such as other applications in your organization or other systems outside your organization sending requests over the internet.

If the user ID and password contained in the web service request has the appropriate permissions, the user can invoke the web service. If the submitted user ID and password fails authentication, then user has no permission to invoke the service. If only a User ID is provided, the PeopleSoft system attempts to verify if the user ID is a valid PeopleSoft user. If the verification fails, the system checks if the request is from a trusted node, then uses the external user ID and password associated with the node from which the request was generated. If the request is not from a trusted node, the system checks the user ID associated with the ANONYMOUS node. How PeopleSoft Integration Broker handles authenticating web service request permissions is discussed in detail in the PeopleSoft Integration Broker PeopleBook.

See Setting Up Secure Integration Environments.

Access the Permission Lists - Web Services page.

Add the web services to which a permission list should have access. Add and remove web services to and from the list using the standard plus and minus buttons.

Note. Web service requests contain user IDs. For the web service to be invoked, the submitted user ID must be valid in the PeopleSoft system. For example, the user account cannot be locked, the request must be submitted during the user ID's valid signon times, and the user ID must have permission to invoke the web service operation.

Web Services

Service	The name of the web service defined in the PeopleSoft system.
Edit	Click to launch the Web Service Permissions page.
Full Access (All)	Grants full access to all services listed on the page.
No Access (All)	Sets all services listed on the page to No Access.

Web Service Permissions

Access the Web Service Permissions page (by clicking the Edit link on the Permission Lists-Web Services page).

Service Operation

Each operation performed by the web service appears in the Service Operation list.

Access

Grant access to the operation by selecting Full Access. Deny access by selecting No Access.

Note. By default, the system sets the value to No Access. Make sure to modify the access values to reflect the desired level.

See Also

Integrating with ERP Systems

Configuring WS-Security For WSRP Consumption and Production

Setting Personalization Permissions

Access the Permission Lists - Personalizations page.

Note. Only those personalization options that accept customization are available for your users to modify.

Option Category Level	Displays the high-level grouping of personalizations.
Option Category Group	Shows the further categorizations of personalization options within the category level.
Edit Options	Click to access the Personalization Permissions page and enable specific personalization options for an option catgory group.

See Managing PeopleSoft Personalizations.

Personalization Permissions

Click Edit Options for an option category group on the Permission Lists - Personalizations page to access the Personalization Permissions page.

Enable a particular user personalization option for a permission list.

Category	Displays the category or type of personalization option.
User Option	Displays the internal code name associated with the personalization option.
Description	Displays the text that the users see on the My Personalizations page.
Allow User Option	Select to enable the option for a permission list.

Setting Query Permissions

Access the Permission Lists - Query page.

The Query page has links to the Permission List Access Groups page, where you can define the records to which the user can have access in PeopleSoft Query, and the Query Profile page, where you can define the query operations that the user can perform.

Defining Access Groups

Click Access Group Permissions to access the Permission List Access Groups page.

Access groups are nodes in a query tree, which you build with PeopleSoft Tree Manager. After you’ve built a query tree, you give users access to one or more of its access groups. Then they can generate queries on any tables in the access groups accessible to them.

When you open Query Manager, it displays either an access group structure or an alphabetical list of records to which you have access. Access groups enable you to logically organize the record components to control security access within PeopleSoft Query. It is not a physical representation of your database.

You can generate queries on and retrieve information only from the tables whose record definitions are within these access groups. If, for example, you were querying an order table and wanted to display data from a related table (like the customer name rather than the customer code), you must have both tables—the order table and the customer prompt table—in your access groups.

To create new queries, or even to run existing ones, users must have access rights to the record components used in the queries. After you’ve built your query trees, you must grant users access to them. You can grant and restrict access to entire query trees or portions of them through the Access Groups page.

To add an access group to a permission list:

Open the permission list and select Query, Access Groups Permissions.
Select a tree name.
Select the highest access group that the user can access.

The system displays access groups in the selected query tree only.

The access group that you select should be the highest-level tree group to which this permission list needs access. The Accessible check box is selected by default. For example, users in the ALLPANLS permission list have access to all record components in the EIS_ACCESS_GRP and all access groups below it in the QUERY_TREE_EIS query tree—in other words, to all record components in the tree.
(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.

Note. Because it hinders system performance, don't clear the Accessible check box for lower-level access groups. To restrict access to record components on a particular branch of a tree, consider creating a new tree for those definitions. Attempting to expand an access group that is not accessible causes all access groups below that access group to be loaded into memory.
Save your changes.

Note. When the system loads an access group into memory for the first time, you’ll likely experience a small delay. This delay is the result of a physical database read for each record component that is associated with that access group. For this reason, don't group a large number of record components into a single access group.

Defining Query Profiles

Access the 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.

Note. The first level of security is access to PeopleSoft Query itself. Not every user needs to create queries. You grant access to the Windows client of PeopleSoft Query by selecting the Query Access check box on the PeopleTools page of a permission list. You grant access to PIA-based Query Manager by including the QUERY_MANAGER menu and its related components on the Pages page of a permission list.

You select at least one of the options in the PeopleSoft Query Use section of this page to give users query access.

PeopleSoft Query Use

Select from:

Only Allowed to run Queries

Select to prevent users from being able to create queries and restrict them from running PeopleSoft Query. The values of the remaining options in this group are irrelevant if you have selected this option.

Note. If you select this option, it only applies to the current permission list. If a user has permission to create public queries through another permission list, then that user can run and create queries against the cumulative set of tables specified through all access groups. For example, assume permission list X has Only Allowed to run Queries selected, and is limited to tables A, B, and C. And, assume permission list Y has Allow creation of Public Queries selected, and is limited to tables B, C, and D. If a user ID has both permission list X and Y associated with it through roles, that user can create Public Queries with tables A, B, C, and D.
Allow creation of Public Queries

Select to enable users to create public queries.
Allow creation of Workflow Queries

Select to enable users to create workflow queries in addition to private queries. A workflow query is used in PeopleSoft Workflow, either as a database agent query or a role query. These queries can circumvent security restrictions; the system doesn’t check access group rights while running the query. To make sure that users can’t bypass the system’s security, clear this check box.
Maximum Rows Fetched.

Enter a number to restruct the number of rows retrieved by a query. Some queries can return many data rows. For performance or time considerations, you may want users to view only some of those rows rather than all of them.

PeopleSoft Query Output

Select at least one:

Run.

PeopleSoft Query displays the query results in a view-only grid control. This option is useful as users are refining their queries.
Run to Excel.

PeopleSoft Query passes the query results to Microsoft Excel, where users can analyze the results further.

Note. If using PeopleSoft Query in the Microsoft Windows environment, you grant runtime access through PeopleSoft Navigator by selecting at least one of the PeopleSoft Query output options.

Advanced SQL Options

Restrict less experienced users from generating complex queries, as such queries can affect system performance.

Setting Mass Change Permissions

Mass change operator security controls:

What mass change templates a user can access to create new definitions.
Whether a user can run mass change definitions online.
What mass change definitions a user can open, view, or run.

These definitions must also be based on a template with the same PeopleSoft owner as the user.

Note. Users inherit mass change authorizations through their primary permission lists, not through roles.

Before you can use a new template to create definitions, you must have permission to access it.

To modify mass change template permissions:

Add or remove templates from the Mass Change Template ID list.
Select or clear OK To Execute Online, as needed.

When you have enabled the OK To Execute Online option, users with the given primary permission list can run mass change definitions after saving any modifications to the Mass Change Definitions pages.
Save your work.

Viewing When a Permission List Was Last Updated

Access the Audit page.

View when a permission list was last updated and by whom. You can also view who has made changes to security tables by using the Database Level Auditing feature.

See Also

Understanding Database Level Auditing

Navigator Homepage	Select a graphic representation of a business process that is displayed by PeopleSoft Navigator. For each security profile definition, you can specify a map to be displayed on startup. If this is the user profile's PeopleSoft Navigator homepage permission list, the system is passed this value at runtime.
Can Start Application Server?	Select to enable user profiles with this permission list to start PeopleSoft application servers. Note. This setting also applies to starting PeopleSoft Process Scheduler servers. Typically, you'll create a user profile that's dedicated to starting application servers. When you define an application server domain, one of the parameters you specify in PSADMIN is the PeopleSoft user ID (and password) for that profile, which must be associated with at least one permission list that has this option enabled. The user ID and password are stored in the Startup section of the PSAPPSRV.CFG file, which BEA Tuxedo reads when the application server is started. In many installations, an application server starts with an automated process. A user profile with this property enabled shouldn't be used by an actual user who signs in to the application server and starts it by submitting the appropriate commands. Note. Password controls don't apply when a password is used for two-tier activities like starting application servers. They apply only when the password is used to sign in over three-tier connections. Important! For a given user profile, the password controls that you set for account lockout (maximum logon attempts) and age (expiration) apply to three-tier and web sign-in only, and don't apply if the user profile is used just for two-tier activities like starting an application server or process scheduler. However, make sure that you don't use the same user profile for both types of activities. When you use it for both three-tier and web sign-in, the profile becomes subject to the account lockout and age controls, which prevents it from completing the two-tier activities.
Allow Password to be Emailed?	Select to enableusers to receive forgotten passwords through email. At some sites, the security administrator may not want passwords appearing unencrypted in any email. You implement this feature by permission list. None can use it, some can use it, or all can use it depending upon your implementation. Users who do not have the proper authority receive an error message if they attempt to have a new password emailed to them.
Never Time-Out and Specific Time-out (minutes)	Select the number of minutes of inactivity allowed at a terminal before the system automatically signs the user out of the PeopleSoft online system. Inactivity means no mouse clicks, keystrokes, import, file print, or SQL activity. The default time-out minutes setting is Never Time-out. Note. Time out limits are also controlled at the web server and application server levels. If you select Never Time-out, an inactive user is never automatically signed out. Otherwise, select Specific Time-out (minutes) and enter the appropriate value in minutes. A custom time-out interval: Must be a positive integer. Can't contain edit characters, such as commas or a $. Must be a SMALLINT in the valid range allowed for this field (0-32767). Entering a value of zero (0) is equivalent to selecting Never Time-out. To comply with the Americans with Disabilities Act (ADA), you might set up most permission lists to time out in 20 minutes, but create a special ADA permission list where timeout occurs after 60 minutes. Note. Because timeout limits are also controlled at the web server level, you'll need to change the web server timeout values also.

Mobile Page Permissions	Click to grant access to mobile application pages.
Menu Name	Displays all menu names in the database. Add new rows to add more menu names. The name reflects the definition name in PeopleSoft Application Designer.
Menu Label	Displays the menu label associated with the PeopleSoft Application Designer menu name.
Edit Components	Click to grant access to specific pages.

Name	Shows the name of the component interface.
Edit	Click to access the Component Interface Permissions page and grant access to a particular component interface method.