PeopleSoft Online Security
The PeopleSoft system has many elements, such as batch processes, object definitions, and application data. Use PeopleTools security tools to control access to most of these elements. To secure other elements, you use application-specific interfaces, such as Administer Security.
This section discusses:
Sign in and time-out security.
Page and dialog box security.
Batch environment security.
Definition security.
Application data security.
PeopleSoft Internet Architecture security.
When a user attempts to sign in to PeopleSoft, he or she enters a user ID and a password on the PeopleSoft Signon page. If the ID and password are valid, PeopleSoft connects the user to the application, and the system retrieves the appropriate user profile.
If the user attempts to sign in during an invalid sign in time as defined in the user's security profile, he or she is not allowed to sign in. A sign in time is an adjustable interval during which a user is allowed to sign in to PeopleSoft. For example, if a given sign in time is Monday through Friday from 7 a.m. to 6 p.m. for a set of users, those users cannot access a PeopleSoft application on Saturday or on Friday at 6:05 p.m. If a user is signed in when the sign in period expires, PeopleSoft signs the user out automatically.
After signing in, a user can stay connected as long as the sign in time allows and as long as the browser does not sit idle for longer than the time-out interval. A time-out interval specifies how long the user’s machine can remain idle—no keystrokes, no SQL—before the PeopleSoft system automatically signs the user out of the application.
You specify both the sign in times and time-out interval using PeopleTools Security.
Note: Other time-out intervals, unrelated to security, are controlled by your web server and by PeopleSoft Pure Internet Architecture components.
You can restrict access to PeopleSoft menus. You can set the access rights to the entire menu, such as Administer Workforce or PeopleTools Security, or just a specific item on that menu. Because the only normal way to access a PeopleSoft page is through a menu, if a user has no access to a particular menu or menu item, then you have effectively restricted that user's access to the corresponding page.
You can also restrict access to specific actions or commands on a page. For example, you may want a clerk in your sales office to be able to access contract data but not be able to update the data. In this case, you grant access to the set of pages, but you allow display-only access only. In this case, the clerk cannot update or correct any data. This approach enables users to get their work done while maintaining the security and integrity of your business data.
If a particular user must run batch processes using PeopleSoft Process Scheduler, assign the appropriate process profile to the user profile and create process groups for your processes. A user receives both process group and process profile authorizations through permission lists. A user gets permission to process groups through roles, and they get a process profile through the process profile permission list.
Note: You add the process profile permission list directly to the user profile, not to an intermediary role.
Process Security
Because PeopleSoft applications take advantage of other applications, such as SQR and COBOL, your batch processes should be run in a secure environment.
The three levels of security for batch programs are:
Each batch program has a run control that you define before you can run the batch program.
Run controls are set up using PeopleSoft Process Scheduler.
PeopleSoft Process Scheduler enables you to set up process groups, which are groups of batch processes.
In PeopleTools Security, you add process groups to a security profile. Users can run processes that belong to the process groups assigned to their security profile.
In your RDBMS environment, you can restrict offline access to batch processes using the security tools described in your platform manuals.
Reporting Security
PeopleSoft Report Manager uses a logical space on a web server called the Report Repository. PeopleSoft Report Manager enables you to generate and distribute reports over the internet, and it stores the output in the Report Repository. Wherever you decide to situate your repository, make sure that the server is protected from outside access. Ensure that only the PeopleSoft system can access and distribute the generated reports. The Report Repository servlet gets items from the web server and puts them in the browser. With report distribution, you distribute reports and view them according to your role.
PeopleSoft delivers these roles for the specific use in reporting:
ReportDistAdmin
ReportSuperUser
Use Definition Security to govern access to database object definitions, such as record definitions, field definitions, and page definitions, and to protect particular object definitions from being modified by certain developers.
Definition security is a form of data security—you use it to control access to particular rows of data (object definitions) in PeopleTools tables. PeopleSoft software also provides other methods to control the application data that a user is allowed to access in the PeopleSoft system. This task is also known as setting data permissions.
With application data security, you can set data permissions at the following levels:
Table level (for queries only).
Row level.
Field level.
Table-Level Security
You use PeopleSoft Query to build SQL queries and retrieve information from application tables. For each PeopleSoft Query user, you can specify the records the user is allowed to access when building and running queries. You do this by creating query access groups in PeopleSoft Tree Manager and then assigning users to those groups with PeopleSoft Query security. PeopleSoft Query security is enforced only when using PeopleSoft Query; it does not control runtime page access to table data.
Row-Level Security
You can design special types of SQL views—security views—to control access to individual rows of data stored within application database tables. Row-level security enables you to specify the data that a particular user is permitted to access. PeopleSoft applications are delivered with built-in row-level security functions that are tailored to specific applications.
For example, PeopleSoft Human Resources security tables enable you to restrict user access to employee rows of data according to organizational roles. You could also permit users to view and update rows for employees in their departments only. Similarly, in PeopleSoft Financials, you can use security views to determine access to business units and ledgers. You can also use security tables to grant privileges by access group to users who use PeopleSoft Query to access data from the database.
See the documentation for your application for details about implementing row-level security for your applications.
Field Security
Use PeopleCode to restrict access to particular fields or columns within application tables. For example, if you want a certain class of user to be able to access certain pages but not to view a particular field on those pages, such as compensation rate, you can write PeopleCode to hide the field for that user class.
PeopleSoft Internet Architecture security is also known as runtime security. Only authorized users can connect to the web and application server, and only authorized application servers can connect to a given database.
PeopleSoft applications use authentication tokens embedded in browser cookies to authorize users and enable single signon throughout the system. To secure links between elements of the system, including browsers, web servers, application servers, and database servers, PeopleSoft applications incorporate a combination of SSL/TLS security and Oracle Tuxedo and Oracle Jolt encryption.
SSL is a protocol developed by Netscape that defines an interface for data encryption between network nodes. TLS, a protocol developed by the Internet Engineering Task Force (IETF), evolved from and is based on SSL.
To establish an SSL/TLS-encrypted connection, the nodes must complete the SSL/TLS handshake. The simplified steps of the SSL/TLS handshake are as follows:
Client sends a request to connect.
Server responds to the connect request and sends a signed certificate.
Client verifies that the certificate signer is in its acceptable certificate authority list.
Client generates a session key to be used for encryption and sends it to the server encrypted with the server's public key (from the certificate received in step 2).
Server uses a private key to decrypt the client generated session key.
Establishing an SSL/TLS connection requires two certificates: one containing the public key of the server (server certificate or public key certificate) and another to verify the certification authority that issued the server certificate (trusted root certificate). The server needs to be configured to issue the server certificate when a client requests an SSL/TLS connection, and the client needs to be configured with the trusted root certificate of the certificate authority that issued the server certificate.
The nature of those configurations depends on both the protocol being used and the client and server platforms. In most cases you replace HTTP with LDAP. SSL/TLS is a lower level protocol than the application protocol, such as HTTP or LDAP. SSL/TLS works the same regardless of the application protocol.
Note: Establishing SSL/TLS connections with LDAP is not related to web server certificates or certificates used with PeopleSoft integration.
The system uses SSL/TLS encryption in the following locations:
Between the browser and the web server.
Between the application server and the integration gateway.
Between the integration gateway and an external system.
The system uses Oracle Tuxedo and Oracle Jolt encryption in these locations:
Between the web server and the application server.
Between the integration gateway and a PeopleSoft system (Oracle Jolt only).
Security between the application server and the database is supplied by RDBMS connectivity.
PeopleSoft Integration Broker and portal products have additional security concerns, which are addressed in the documentation for those products.