Security Basics
This chapter discusses:
Security basics.
PeopleSoft online security.
PeopleSoft authorization IDs.
PeopleSoft sign in.
Implementation options.
Security Basics
Security is especially critical for core business applications, such as PeopleSoft applications. Typically, you do not want every department in your company to have access to all your applications. Nor do you want everyone within a department to have access to all the functions or all the data of a particular application. Additionally, you may want to restrict who can customize your applications with PeopleTools.
PeopleSoft software provides security features, including components and PeopleTools applications, to ensure that your sensitive application data, such as employee salaries, performance reviews, or home addresses, does not fall into the wrong hands. Most likely, you use other security tools for your network and relational database management system (RDBMS). These tools work together to protect the PeopleSoft system from unauthorized access.
As you implement the PeopleSoft Internet Architecture, you need a robust and scalable means by which you can grant authorization to users efficiently. When you deploy your applications to the internet, the number of potential users of your system increases exponentially. Suddenly, you have customers, vendors, suppliers, employees, and prospects all using the same system.
The PeopleSoft security approach is tailored for the internet. It enables you to easily create and maintain security definitions, and you can perform many maintenance tasks programmatically.
You can apply security to all users, including employees, managers, customers, contractors, and suppliers. You group your users according to roles to give them different degrees of access. For instance, there might be an Employee role, a Manager role, and an Administrator role. Users who belong to a particular role require a specific set of permissions, or authorizations, within your system, so that they can complete their daily tasks.
You must also secure the objects and definitions in your PeopleSoft development environment. Just as you restrict sets of end users from accessing particular pages and components, you also restrict the definitions that your site’s developers can access using PeopleSoft Application Designer. A definition refers to any of the definitions that you create within PeopleSoft Application Designer, such as records, pages, or components. Each object definition may have individual security needs. For example, you may have a large development staff, but perhaps you want only a few developers to have access to specific record definitions.
PeopleSoft Security Definitions
Because deploying your applications to the internet significantly increases the number of potential users your system must accommodate, you need an efficient method of granting authorization to different user types. PeopleSoft security definitions provide a modular means to apply security attributes in a scalable manner.
A security definition refers to a collection of related security attributes that you create using PeopleTools Security. The three main PeopleSoft security definition types are:
User profiles.
Roles.
Permission lists.
Note. A PeopleSoft security definition called an Access Profile also exists, but these are defined at the database level.
User profiles define individual PeopleSoft users.
Each user has an individual user profile, which in turn is linked to one or more roles. You add one or more permission lists, which ultimately control what a user can and cannot access, to each role. A few permission types are assigned directly to the user profile.
Typically, a user profile must be linked to at least one role in order to be a valid profile. The majority of values that make up a user profile are inherited from the linked roles.
Roles are intermediate objects that link user profiles to permission lists. You can assign multiple roles to a user profile, and you can assign multiple permission lists to a role. Some examples of roles might be Employee, Manager, Customer, Vendor, and Student.
A manager is also an employee and may also be a student. Roles enable you to mix and match access appropriately.
You have two options when assigning roles: assign roles manually or assign them dynamically. When assigning roles dynamically, you use PeopleCode, LDAP, and PeopleSoft Query rules to assign user profiles to roles programmatically.
Permission lists are groups of authorizations that you assign to roles. Permission lists store sign in times, page access, PeopleTools access, and so on.
A permission list may contain one or more types of permissions. The fewer types of permissions in a permission list, the more modular and scalable your implementation.
A user profile inherits most of its permissions through roles, but you apply some permission lists, such as process profile or row-level security (data permissions), directly to a user profile.
See Also
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.
Sign in and Time-out 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.
Page and Dialog Box Security
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.
Batch Environment Security
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.
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
Definition Security
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.
Application Data Security
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.
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.
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.
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
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.
See Also
Setting Up Secure Integration Environments
PeopleSoft Applications Portal 9.1: Portal and Site Administration PeopleBook, Part 5: Integration
PeopleSoft Authorization IDs
The PeopleSoft system uses various authorization IDs and passwords to control user access. You use PeopleTools Security to assign two of these IDs: the user ID and the symbolic ID.
This section discusses:
User IDs.
Connect ID.
Access IDs.
Symbolic IDs.
Administrator access.
See Also
User IDs
A PeopleSoft user ID is the ID you enter at the PeopleSoft sign in page. You assign each PeopleSoft user a user ID and password. The combination of these two items grants users online access to the PeopleSoft application. The system can also use a user ID stored within an LDAP directory server.
The user ID is the key that the application uses to identify the user profile definition.
Connect ID
The connect ID performs the initial connection to the database.
Note. PeopleSoft no longer creates users at the database level.
A connect ID is a valid user ID that, when used during sign in, takes the place of PeopleSoft user IDs. Using a connect ID means you do not have to create a new database user for every PeopleSoft user that you add to the system.
Note. A connect ID is required for a direct connection (two-tier connection) to the database. Application servers and two-tier Microsoft Windows clients require a connect ID. You specify the connect ID for an application server in the Signon section of the PSADMIN utility. For Microsoft Windows clients, you specify the connect ID on the Startup tab of PeopleSoft Configuration Manager. You can create a connect ID by running the ConnectSQL and GrantSQL scripts.
Note. When performing a database compare or copy, both databases must have the same connect ID.
Warning! Without a connect ID specified, the system assumes the workstation is accessing PeopleSoft through an application server. The option to override the database type is disabled.
Access IDs
When you create any user ID, you must assign it an access profile, which specifies an access ID and password.
The PeopleSoft access ID is the RDBMS ID with which PeopleSoft applications are ultimately connected to your database after the PeopleSoft system connects using the connect ID and validates the user ID and password. An access ID typically has all the RDBMS privileges necessary to access and manipulate data for an entire PeopleSoft application. The access ID should have Select, Update, and Delete access.
Users do not know their corresponding access IDs. They just sign in with their user IDs and passwords. Behind the scenes, the system signs them into the database using the access ID.
If users try to access the database directly with a query tool using their user or connect IDs, they have limited access. User and connect IDs only have access to the few PeopleSoft tables used during sign in, and that access is Select-level only. Furthermore, PeopleSoft encrypts the sensitive data that resides in those tables.
Note. Access profiles are used when an application server connects to the database, when a Microsoft Windows workstation connects directly to the database, and when a batch job connects directly to the database. Access profiles are not used when end users access applications through PeopleSoft Pure Internet Architecture. During a PeopleSoft Pure Internet Architecture transaction, the application server maintains a persistent connection to the database, and the end users leverage the access ID that the application server domain used to sign in to the database.
Note. PeopleSoft suggests that you only use one access ID for your system. Some RDBMS do not permit more than one database table owner. If you create more than one access ID, it may require further steps to ensure that this ID has the correct rights to all PeopleSoft system tables.
Symbolic IDs
PeopleSoft encrypts the access ID when it is stored in the PeopleTools security tables. Consequently, an encrypted value cannot be readily referenced or accessed. So when the access ID, which is stored in PSACCESSPRFL, must be retrieved or referenced, the query selects the appropriate access ID by using the symbolic ID as a search key.
The symbolic ID acts as an intermediary entity between the user ID and the access ID. All the user IDs are associated with a symbolic ID, which in turn is associated with an access ID. If you change the access ID, you need to update only the reference of the access ID to the symbolic ID in the PSACCESSPRFL table. You do not need to update every user profile in the PSOPRDEFN table.
Administrator Access
As an administrator, you must customize your own user definition. PeopleSoft delivers at least one full-access user ID with each delivered database. Your first task should be to sign in with this ID and personalize it for your needs or to create a new, full-access ID, being sure to specify a new password. You should change the passwords of all delivered IDs as soon as possible.
Note. PeopleSoft-delivered IDs and passwords are documented in your installation manual.
When you install PeopleSoft, you are prompted for an RDBMS system administrator ID and password. This information is used to automatically create a default access profile. If you will be using more than one access profile, set up the others before creating any new PeopleSoft security definitions. Most sites only use one access profile.
The number of database-level IDs you create is up to your site requirements. However, in most cases, having fewer database-level IDs reduces maintenance issues.
For example, if you implement pure LDAP authentication, at a minimum you need two database-level IDs—your access ID and your connect ID. With this scenario, in PeopleSoft you need to maintain only a symbolic ID to reference the access ID and maintain a user ID that the application server uses during sign in. With this minimal approach, each user who needs a two-tier connection, to run an upgrade, for example, could use the same user ID that the application server uses.
PeopleSoft Sign In
This section discusses:
PeopleSoft sign in process.
Directory server integration.
Authentication and Signon PeopleCode.
Single signon.
PeopleSoft Sign In Process
The most common direct sign in to the PeopleSoft database is the application server sign in.
These are the basic steps that are taken when the application server signs in to the database:
Initial connection.
The application server starts and uses the connect ID and user ID specified in its configuration file (PSAPPSRV.CFG) to perform the initial connection to the database.
The server performs a SQL Select statement on the PeopleTools security tables.
After verifying the connect ID, the application server performs a Select statement on PeopleTools security tables, such as PSOPRDEFN, PSACCESSPRFL, and PSSTATUS. Using these tables, the application server authenticates the user and gathers such items as the user ID and password, symbolic ID, access ID, and access password. After the application server has the required information, it disconnects.
The server reconnects using the access ID.
When the system verifies that the access ID is valid, the application server begins the persistent connection to the database that all PeopleSoft Pure Internet Architecture and Microsoft Windows three-tier clients use to access the database. Typically, the users signing in using a Microsoft Windows workstation are developers using PeopleSoft Application Designer.
Note. A Microsoft Windows workstation attempting a two-tier connection uses the same process as the application server.
PeopleSoft recommends that all connectivity be made through either a three-tier Microsoft Windows client or through the browser. A two-tier connection is not necessary other than for the application server, PeopleSoft Process Scheduler, or for a user who will be running upgrades or PeopleSoft Data Mover scripts.
Signon PeopleCode does not run during a two-tier connection, so maintaining two-tier users in a directory server is not supported.
Directory Server Integration
PeopleSoft recognizes that your site uses software produced by numerous vendors, and each different product requires security authorizations for users. Most of these products adhere to the model that includes user profiles and roles (or groups) to which users belong. PeopleSoft enables you to integrate your authentication scheme for the PeopleSoft system with your existing infrastructure. You can reuse user profiles and roles that are already defined within an LDAP directory server.
Organizations typically store user profiles in a central repository that serves user information for all of the programs that require it. The central repository is typically an LDAP directory server.
A directory server enables you to maintain a single, centralized user profile that you can use across all of your PeopleSoft and non-PeopleSoft applications. This approach reduces redundant maintenance of user information stored separately throughout your enterprise, and it reduces the possibility of user information getting out of synchronization.
You always maintain permission lists and roles by using PeopleTools Security. However, you can maintain user profiles in PeopleTools Security or with an external directory server.
See Also
Employing LDAP Directory Services
Authentication and Signon PeopleCode
You can store PeopleSoft passwords in the PSOPRDEFN PeopleTools table. You can also store and maintain user passwords and the rest of the user profile data in an LDAP directory server. PeopleSoft applications retrieve the information stored in an external directory server using a combination of the User Profiles component interface and Signon PeopleCode.
If you decide to reuse existing user profiles stored in a directory server, you don’t need to perform dual maintenance on the two copies of the user data—one copy in the LDAP server and one copy in PSOPRDEFN. PeopleSoft applications ensure that the user information stays synchronized. If you configure LDAP authentication, you maintain your user profiles in LDAP and not in PeopleTools Security.
Signon PeopleCode copies the most recent user profile data from a directory server to the local database whenever a user signs in. PeopleSoft applications reference the user information stored in the PeopleSoft database rather than making a call to the directory server each time the system requires user profile information. Signon PeopleCode ensures the local database has a copy of the most current user profile based on the information in the directory. Each time the user signs in, Signon PeopleCode checks to see to see if the row in the user profile cache needs to be updated.
The sign in process occurs as follows:
The user enters a user ID and password on the sign in page.
PeopleTools attempts to authenticate the user against the PSOPRDEFN table.
Signon PeopleCode runs.
The default Signon PeopleCode program updates the user profile based on the current data stored in the directory server.
You can use Signon PeopleCode and business interlinks to synchronize the local copy of the user profile with any data source at sign in time; the program that ships with PeopleTools is designed to synchronize the user profile with an LDAP directory server only. Because the sign in program is PeopleCode, you can modify it, incorporating any of the PeopleSoft integration technologies that PeopleCode supports.
To edit the Signon PeopleCode program, you open the LDAP function library record and use the PeopleCode editor to customize the PeopleCode programs. Developers who modify the Signon PeopleCode program need to have a good understanding of PeopleCode and the integration features it offers.
Note. Only users who sign in through PeopleSoft Pure Internet Architecture or three-tier Microsoft Windows clients take advantage of Signon PeopleCode.
Single Signon
PeopleSoft Pure Internet Architecture uses browser cookies for seamless single signon across all PeopleSoft nodes. A node refers to a database and the application servers connected to it. For example, a user can complete a PeopleSoft Human Resources transaction, and then click a link for a PeopleSoft Financials transaction without reentering a password. Single signon is especially important to the PeopleSoft portal, which aggregates content from several different applications and data sources into a single, integrated display.
See Also
Working with SSL/TLS and Digital Certificates
Implementation Options
By using our integration technologies, you can configure PeopleSoft security to work with numerous schemes.
This section discusses:
Authentication options.
Role assignment options.
Cross-system synchronization options.
Authentication Options
Consider how you plan to authorize users as they sign in to your PeopleSoft system. Do you want to store and maintain the PeopleSoft user passwords within a PeopleSoft database, or do you plan to take advantage of existing user profiles in an external directory server?
PeopleSoft-Based Authentication
This option is, generally, the way PeopleSoft customers have authorized users in previous releases. PeopleSoft user passwords are stored and maintained solely within PeopleSoft. Although this method does not require a large amount of storage, it does add administration issues, mainly because PeopleSoft passwords are yet another password users need to remember.
With this option there are only two database-level IDs, the access ID and the connect ID. The passwords reside in the PSOPRDEFN along with the other user information.
Directory-Based Authentication
You can also use a central repository for user information in a directory server that uses the LDAP protocol.
The advantage of this option is that a user has one user ID and password that allows access to numerous software systems.
See Also
Role Assignment Options
Consider how you plan to assign authorizations to your users. Recall that users inherit permissions through the roles to which they are assigned. When you plan your authorization assignment, you are really planning how you intend to assign roles to users. You can assign roles to users in two ways: the static approach and the dynamic approach.
Using the static approach, you assign users to roles manually. Static role assignment is not scalable to the thousands of users that are likely to use your system when you deploy applications to the internet.
The static approach requires an administrator to maintain each user's set of roles. For that reason, Oracle recommends that you explore and implement the dynamic role assignment.
Using dynamic role assignment, the system assigns roles based on business rules. You can manually run the rule, but typically, you run the rules from a scheduled batch process.
Suppose an employee changes jobs and becomes a manager in a new department. When you run your dynamic rule, the system removes the roles associated with the employee's previous position and then adds the appropriate roles required for the new position. In addition, you can have the rule publish a message to other nodes, such as a PeopleSoft Financials node, which might subscribe to changes in the PeopleSoft Human Resources database.
You can use PeopleSoft Query, LDAP, or PeopleCode to define dynamic role assignment. If necessary, you can use a combined approach with the rules for assigning roles. For example, you can have one role rule based on LDAP, another based on a query, and so on. You can also have multiple rule types for one role. For example, a Manager role could be derived partially from an LDAP rule and partially from a PeopleSoft Query rule. As the following list describes, where the information that drives your role assignments is stored determines the types of role rules you use:
If the membership data for your roles resides in your PeopleSoft database, use PeopleSoft Query to construct your role rules.
One query could be MANAGER, another EMPLOYEE, and so on. When the rule runs, the system assigns your employee users to the EMPLOYEE role and the manager employees to the MANAGER role based on the results returned from the query.
If you already have LDAP directory server groups organized by region, department, position, and so on, base your rules on the existing LDAP structure.
Based on the directory setup and hierarchy, your rule assigns PeopleSoft users to the appropriate roles. Your PeopleSoft application uses your existing LDAP configuration. You should use this role rule type in conjunction with LDAP authentication.
If you have user information in other third-party systems, such as legacy mainframe applications or UNIX account groups, use PeopleCode.
You can take advantage of the multiplicity of integration technologies that PeopleCode supports, such as business interlinks and component interfaces. The business interlinks retrieve the data from the external system and write it to the role assignment tables in the PeopleSoft database.
Cross-System Synchronization Options
If you have multiple PeopleSoft applicationos, consider how to keep user information synchronized. Synchronization is especially important for the portal deployment, where users are likely to move from one system to another seamlessly. For instance, after completing a transaction in PeopleSoft Human Resources, a user may click a link that takes her directly to PeopleSoft Financials.
If you are using dynamic role assignment, the dynamic role batch program, by default, publishes a message that indicates a particular change. You need to make sure that nodes that require such information changes are configured to subscribe to the message that publishes the changed data. For example, suppose PeopleSoft Financials needs a list of managers for a particular transaction. Because the manager information resides in PeopleSoft Human Resources, PeopleSoft Human Resources publishes any changed information to PeopleSoft Financials to keep the data synchronized.
PeopleSoft security also publishes a message when a user profile changes (if the corresponding Service Operation version is active), which is most useful if you are not using LDAP to store user information. If you store user information in the PeopleSoft system, the message makes sure that password changes are replicated across multiple databases. If you store your user information in a central LDAP server, then the passwords, and so on, are already—in a sense—synchronized.
You can upgrade permission lists and roles using the PeopleSoft Application Designer upgrade features. For user information, PeopleSoft Data Mover scripts migrate user profiles between systems for upgrades or bulk loads.