Implementation Options

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.

Static

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.

Dynamic

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.