By using our integration technologies, you can configure PeopleSoft security to work with numerous schemes.
This section discusses:
Role assignment options.
Cross-system synchronization 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?
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.
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.
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.
If you have multiple PeopleSoft applications, 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.