Employing LDAP Directory Services

This chapter provides an overview of the PeopleSoft Lightweight Directory Access Protocol (LDAP) solution and discusses how to:

Note. PeopleTools uses JNDI libraries only. JNDI requires no added installation as it is part of the standard PeopleTools installation.

This chapter assumes you have a working knowledge of LDAP-enabled directory servers.

Click to jump to parent topicUnderstanding the PeopleSoft LDAP Solution

Three PeopleSoft-delivered technologies enable you to:

The three technologies are:

The combination of these three technologies provides a flexible way to configure PeopleSoft for integration with your directory server. No set schema is required in the directory. Instead, you can configure and extend the Signon PeopleCode to work with any schema implemented in your directory server.

The topics in this chapter describe setting up the LDAP integration technology on your site. The tasks assume that an LDAP V3 compliant directory service is already installed, and that you intend to import LDAP group values and apply them to PeopleSoft roles.

Note. When you enable LDAP authentication, the password column on the PSOPRDEFN record is no longer used. Directory-level users are not authenticated against the PSOPRDEFN table; they are authenticated by signon PeopleCode. Because signon PeopleCode only runs on the application server, LDAP authentication requires an application server. That is, LDAP authentication does not work for a two-tier signon.

Click to jump to parent topicConfiguring the LDAP Directory

This section provides an overview of LDAP directory configuration and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding LDAP Directory Configuration

The Configure Directory component (PSDSSETUP) contains four pages that you use for specifying connection information and testing directory server connections.

To enable your PeopleSoft system to successfully connect to your directory server, you must enter the appropriate connection information. This information includes the server name (DNS or IP address) and the listening port number. You also must enter the user distinguished name (User DN) and associated password.

The PeopleSoft application server uses the User DN and password to connect to the LDAP server to retrieve user profile information about the specific user signing in to the system. The User DN must reflect a user with the appropriate LDAP browse rights.

Click to jump to top of pageClick to jump to parent topicPages Used to Configure the Directory

Page Name

Definition Name

Navigation

Usage

Directory Setup

DSDIRSETUP

PeopleTools, Security, Directory, Configure Directory, Directory Setup

Specify the network information of your LDAP directory servers, such as sign-in IDs and passwords.

Additional Connect DN's

DSSERVERID

PeopleTools, Directory, Configure Directory, Additional Connect DN's

Specify connect DNs in addition to the default connect DN specified on the Directory Setup page.

Schema Management

DSEXTINSTALL

PeopleTools, Security, Directory, Configure Directory, Schema Management

Install selected PeopleSoft-specific schema extensions into your directory.

Test Connectivity

DSSRCHRSLT

PeopleTools, Security, Directory, Configure Directory, Test Connectivity

Test the distinguished names and search criteria that you entered on the previous pages of the Configure Directory component and view the results. The system tests the connectivity when you access this page.

Click to jump to top of pageClick to jump to parent topicSpecifying Network Information for LDAP

Access the Directory Setup page (PeopleTools, Security, Directory, Configure Directory. Click the Directory Setup tab).

Directory ID

Displays the directory connection that you are creating. The directory ID that you enter can identify a specific LDAP server or a collection of LDAP servers, depending on how many servers you add in the Server Name section.

Description

Enter a description of the directory connection.

Directory Product

Select your directory product from the list of options.

Default Connect DN (default connect distinguished name)

Displays the default connect DN associated with the directory ID that you entered or selected on the initial search page. The connect DN is the ID that you can use to connect to the directory server. You can enter an alternative connect DN.

Password

Enter the password associated with the directory-based account that appears in the Default Connect DN field.

Note. The password is stored in encrypted form in the database; not even individuals with administration access to the database can view the password.

Server Name

Add LDAP directory servers to a connection list. You can add multiple servers for failover purposes using the plus button. All servers you add must participate in the same directory service.

LDAP Server

Identify a specific LDAP server. You can use the DNS name or you can use IP address dotted notation. For example, either of the following formats is acceptable: ldap12.yourcompany.com or 192.201.185.90.

Port

Enter the port number on which the LDAP server is configured to receive search requests. The standard LDAP port is 389. If you do not specify the correct port, PeopleSoft Directory Interface cannot exchange data with your LDAP server.

SSL Port

If you are implementing SSL, enter the SSL port on the LDAP server.

Click to jump to top of pageClick to jump to parent topicSpecifying Additional Connect DNs

Access the Additional Connect DN’s page (select PeopleTools, Directory, Configure Directory and click the Additional Connect DN's tab).

The PeopleSoft application server uses the User DN and password specified on this page to connect to the LDAP server to retrieve user profile information about the specific user signing in to the system. The User DN must reflect a user with the appropriate LDAP browse rights.

Note. You will not see any available schema extensions unless you have installed the PeopleSoft Directory Interface.

User DN

Add any DNs that you need in addition to the default connect DN that you entered on the Directory Setup page. The default user ID is most likely an administrative ID. This value enables you to set up a more secure user ID for the scope of the mapping.

Password

For each additional DN that you enter, add the corresponding password.

Click to jump to top of pageClick to jump to parent topicInstalling Selected PeopleSoft-Specific Schema Extensions

Access the Schema Management page (select PeopleTools, Security, Directory, Configure Directory and click the Schema Management tab).

Note. Unless you have installed the PeopleSoft Directory Interface product, you might not have any PeopleSoft schema extensions available to you.

Note. The Schema Management page enables you to add PeopleSoft-delivered object classes and attribute types to your directory. If you add attributes and object classes using the Schema Management page, you must also delete them using this page.

Apply

Select this check box to apply the selected schema extension type to your directory.

Type

Displays the type of schema extension, either Object Class or Attribute Type.

Name

Displays the schema extension name.

Object Identifier

Displays the schema extension object identifier. The sequence 1.3.6.1.4.1.2810.20 identifies the object as a PeopleSoft object. The second to last number is either a 1 or a 2. A 1 indicates an object class type and a 2 indicates an attribute type. The last number indicates the sequence in which the extension was created.

Revision

Displays the number of times the schema extension was revised.

Details

Click to display details about the selected schema extension in the Details region at the bottom of the page.

Select All

Click to select all the schema extensions to apply to your directory.

Deselect All

Click to deselect every schema extension.

Apply

Click to apply the selected schema extensions to your directory.

Details

When you click a schema extension Details button, the system displays the details of that extension. In addition to the object identifier and name, you may also be interested in the Superiors detail, which indicates which extensions, if any, are above this one in the hierarchy. Also of interest is the Type detail, which indicates whether the schema extension is a mandatory, optional, or auxiliary extension.

Schema Cache Information

For convenience, you can use the Schema Cache Process link to transfer you to the Schema Cache page so that you can invoke the Schema Cache process. Last Update Date/Time and Last Update User ID enable you to monitor the frequency of updates as well as the last administrator to run the process.

Click to jump to top of pageClick to jump to parent topicTesting Connectivity

Access the Test Connectivity page (select PeopleTools, Security, Directory, Configure Directory and click the Test Connectivity tab).

The page displays the results (SUCCESS or FAIL) of the connectivity test. If connectivity fails, modify the connect information on the Directory Setup and Additional Connect DN’s pages.

Click to jump to parent topicCaching the Directory Schema

You use the Cache Schema page to specify a directory server and invoke an Application Engine program designed to create a cache in the PeopleSoft database of the directory schema. This cache enables you to select names of object classes and attribute types when you create security maps.

This section discusses how to create a cache of the directory schema.

Click to jump to top of pageClick to jump to parent topicPage Used to Cache the Directory Schema

Page Name

Definition Name

Navigation

Usage

Cache Schema

DSSCHEMACACHE

PeopleTools, Security, Directory, Cache Directory Schema

Specify a directory server and invoke an Application Engine program designed to create a cache in the PeopleSoft database of the directory schema. The cache of the LDAP schema is used to simplify creating maps for authentication and user profile maintenance.

Click to jump to top of pageClick to jump to parent topicCreating a Cache of the Directory Schema

Access the Cache Schema page (PeopleTools, Security, Directory, Cache Directory Schema).

Directory ID

Select the directory ID to identify the directory that the system should connect to and retrieve schema information from.

Server Name

Search for the Process Scheduler server on which the Cache Schema process should run.

Cache Schema Now

Click this button to cache the LDAP schema data to tables within the PeopleSoft database. Typically, you use this option during initial setup and any time that the schema has changed.

Process Monitor

After invoking the process, you can monitor the progress by clicking this link.

Click to jump to parent topicCreating Authentication Maps

Use the Authentication page only if you are implementing directory authentication as opposed to storing authentication information in the PeopleSoft database. You create authentication maps to define mappings to one or more directories that the PeopleSoft system relies on for authenticating users. You can activate multiple authentication maps. Your PeopleSoft LDAP system authenticates users against all active authentication maps.

Authentication maps are used to specify the following information for LDAP authentication:

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicPage Used to Create Authentication Maps

Page Name

Definition Name

Navigation

Usage

Authentication

DSSECMAPMAIN

PeopleTools, Security, Directory, Authentication Map

Create a mapping to the directory that the PeopleSoft system relies on for authenticating users.

Click to jump to top of pageClick to jump to parent topicDefining an Authentication Map

Access the Authentication page (PeopleTools, Security, Directory, Authentication Map).

Status

Activate the authentication map by selecting Active. To disable an authentication map, select Inactive.

Directory Information

Directory ID

Select the directory ID of the directory that you intend to use for authentication.

Anonymous Bind

If all directory data required for authentication and user profile maintenance is visible to an anonymous connection, select this check box.

Use Secure Socket Layer

Select this option if you are implementing an SSL connection between PeopleSoft and the directory.

If you did not specify a port number for the directory, the system uses the default LDAPS port.

Connect DN

This value is the default connect DN that you specified on the Directory Setup page. To select one of the DNs specified on the Additional Connect DN's page, click the search button.

Note. If Anonymous Bind is selected, the Connect DN is ignored.

User Search Information

Search Base

Enter the root of the directory information tree under which the system should search for user information.

Search Scope

Select the search scope for this search. Values are:

Base: Not applicable. You should not use Base on the authentication map.

One: The query searches only the entries one level down from the entry in the Search Base field.

Sub: The query searches the entire sub tree beneath the search base entry.

Search Attribute

When a user signs on using LDAP Authentication, the system searches the directory to find the user's user entry. The search attribute is used to construct the LDAP search filter used in finding the person’s user entry. The value in the Search Attribute field is entered by the user when the user signs on.

Enter the attribute to be returned by the search, such as user ID (uid) or customer ID (cid).

See Using the Search Attribute Field in Authentication Maps.

Important! If you specify a different value here than the User ID Attribute value that you plan to specify on the Mandatory User Properties page, users will not be able to switch to another application from the Go menu in PeopleSoft Windows clients such as Application Designer.

The second application expects to automatically authenticate a user with the value of %SignonUserId, the system variable that contains the value entered by the user in this field. However, the value of the User ID Attribute field is used to populate the OPRID field in PSOPRDEFN. Because the value of OPRID is different from the value of %SignonUserId, the authentication fails with an error message.

Users can still access any PeopleSoft Windows client by launching it directly and signing in using the value of this field as the user ID.

Search Filter

Displays the LDAP search filter that the system uses to search the directory for equal entries.

List of Servers

SeqNum (sequence number)

Set the order in which the system should access the list of servers for authentication.

LDAP Server

Select the name of the LDAP server. Use the plus button to enter additional servers.

Click to jump to top of pageClick to jump to parent topicUsing the Search Attribute Field in Authentication Maps

The purpose of the Search Attribute prompt on the authentication maps page is to map a value that is used for the User ID on the login page. For example, if you want users to log in with their mailID, then mail attribute should be given in the prompt.

Example

Consider an entry corresponding to the user sramdass in the LDAP directory.

dn: uid=sramdass, dc=peoplesoft, dc=com cn: sramdass uid: sramdass123 description: peoplesoft user mail: sramdass@oracle.com telephone: 12345678 objectclass: person password: PASSWORD

If the user is to log in with sramdass/PASSWORD, then the Search Attribute prompt value should be cn. If the user wants to log in with sramdass@oracle.com/PASSWORD, then the Search Attribute prompt value should be mail.

Click to jump to parent topicCreating User Profile Maps

This section provides an overview of user profile options and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding User Profile Options

If you are going to authenticate users with the directory server, a PeopleSoft user profile is still required. That is, a row is still required in the table in which PeopleSoft user information is stored (PSOPRDEFN). In this context, you cache LDAP user information inside your PeopleSoft system. The properties that you specify on the Mandatory and Optional User Properties pages are the columns in PSOPRDEFN that the system populates with values from your directory server. These values comprise your user profile options.

PeopleSoft applications use this cache of user information, not your directory server. Whenever a transaction requires user information, the application refers to the local PSOPRDEFN table as opposed to querying the directory server. This improves performance.

After a user signs on to the system and the Signon PeopleCode is carried out, PeopleSoft creates a row for that user in the user definition table by retrieving the LDAP information and creating a local cache. Signon PeopleCode maintains this row automatically; manual updates are not necessary. Any changes made in the directory server are reproduced in the local cache.

Some properties are required when creating a PeopleSoft User Profile; these properties appear on the Mandatory User Properties page. Other properties are optional; these properties appear on the Optional User Properties page.

Note. You must supply user properties to Signon PeopleCode only if you intend to authenticate users with your LDAP directory.

Click to jump to top of pageClick to jump to parent topicPages Used to Create User Profile Maps

Page Name

Definition Name

Navigation

Usage

Mandatory User Properties

DSUSRPRFLMANMAP

PeopleTools, Security, Directory, User Profile Map, Mandatory User Properties

Specify the attributes required for signon. You can select to have the system retrieve these mandatory values from the directory server, or you can enter default values.

Optional User Properties

DSUSRPRFLOPTMAP

PeopleTools, Security, Directory, User Profile Map, Optional User Properties

Specify optional user properties to retrieve from the directory.

Click to jump to top of pageClick to jump to parent topicSpecifying Mandatory User Properties

Access the Mandatory User Properties page (select PeopleTools, Security, Directory, User Profile Map and click the Mandatory User Properties tab).

Authentication Map

Select the authentication map to associate with this user profile mapping. The server and connection information are taken from the authentication map.

Status

Displays the status of the selected user profile map.

Note. Only one user profile map should be active at any time.

Directory ID

Displays the directory ID associated with the authentication mapping.

User ID Attribute

Specify the LDAP attribute used to populate the OPRID (user ID) field on PSOPRDEFN.

Important! If you specify a different value here than the Search Attribute value that you specified on the Authentication page, then users will not be able to switch to another application from the Go menu in PeopleSoft Windows clients such as Application Designer.

The second application expects to automatically authenticate a user with the value of %SignonUserId, the system variable that contains the user ID that was used to sign in. However, because the value of OPRID is different from the value of %SignonUserId, the authentication fails with an error message.

Users can still access any PeopleSoft Windows client by launching it directly and signing in using the same Search Attribute value for the user ID.

ID Type

ID Type

Enter the default ID type for new users, such as Employee ID, Customer ID, and so on. This field is similar to Symbolic ID.

ID Type Attribute

Specifies the LDAP attribute in the directory that holds the selected ID value. For instance, the ID value might be Employee ID. Some ID types require additional data when creating a profile of that type. LDAP User Profile Management can retrieve that data from the LDAP directory if it is available.

Default Role

Use Default Role

Select this option if you want to use the default role. If you enable this option, the Default Role edit box becomes available for entry while the Role Attribute field becomes unavailable for entry. You either specify a default role or specify an LDAP attribute on the user entry that holds the valid name of a PeopleSoft role.

Role Name

Enter the name of a default role to be assigned to new users. This value applies to users the first time that they sign on and have not had any roles dynamically assigned to them. Typically, this role has only basic access authorizations, such as for only the self-service pages. Users should get most of their permissions through dynamically assigned roles.

Role Attribute

Instead of specifying only a single default role for each and every user, you can enter a value for the LDAP attribute that holds the name of a PeopleSoft role to be assigned to the user.

You can enable your application to automatically apply a role for the user. When signing in to the application, the user provides a value for the search attribute you specified in the authentication map. The system uses that attribute value to search for the user's entry in the LDAP directory, and then imports the groups containing the entry to the PSOPRDEFN table as the user's role.

To enable this automatic role import feature:

  1. Define LDAP groups with names that exactly match the roles defined for your application and assign the user to groups.

  2. Deselect the Use Default Role check box on this page.

  3. Leave the Role Name and Role Attribute fields on this page blank.

Language

Use Default Language Code

Select if you do not maintain language codes in the directory.

Language Code

If the default language code is not stored in the directory, select a default value from the drop-down list box.

LangCD Attribute (language code default)

The name of the LDAP attribute containing a valid language code. The value retrieved from the attribute must be a valid PeopleSoft language code.

Click to jump to top of pageClick to jump to parent topicSpecifying Optional User Properties

Access the Optional User Properties page (PeopleTools, Security, Directory, User Profile Map, Optional User Properties).

User Profile Property

Select the user profile property that you want to add to the local cache. These properties are described in the following table.

Use Constant Value

To supply a constant value for each user, select this option.

Attribute Name

Add the name of the attribute as it is represented in your LDAP schema.

Constant Value

Appears only if you selected Use Constant Value.

Always Update

Select this option if you always want the system to update the local user cache to reflect the data stored in the directory server every time the user signs on. If Always Update is not selected, the data will be taken from the directory only when the profile is first created.

Click the User Profile Property search button to select one of the following optional user profile properties:

CurrencyCode

If the user deals with international prices, set the currency code to reflect the native or base currency so that values appear in the currency with which the user is familiar.

EmailAddress

Select if a user is part of your workflow system or you have other systems that generate emails for users.

MultiLanguageEnabled

Select if the user is set up to use PeopleSoft with multiple languages.

NavigatorHomePermissionList

Displays the homepage permission list that is associated with PeopleSoft Workflow (Navigator Homepage).

PrimaryPermissionList

PeopleSoft determines which data permissions to grant a user by examining the primary permission list and row security permission list. Which one is used varies by application and data entity (employee, customer, vendor, business unit, and so on). Consult your PeopleSoft application documentation for more details. PeopleSoft also determines mass change and definition security permissions from the primary permission list.

ProcessProfilePermissionList

The process profile contains the permissions that a user requires for running batch processes through PeopleSoft Process Scheduler. For example, the process profile authorizes users to view output, update run locations, restart processes, and so on. Only the process profile comes from this permission list, not the list of process groups.

RowSecurityPermissionList

See explanation for the Primary Permission List field.

SymbolicID

If the symbolic ID is required for the user, select this option.

UserDescription

Typically, displays the name of the user, such as an employee name or a vendor name.

UserIDAlias

In some cases, the user ID is an alias in the form of an email address. If so, select this option.

Click to jump to top of pageClick to jump to parent topicAssociating User IDs and User Profile Maps

When a user is authenticated, a user profile must be created in the PeopleSoft database without a password. Every user profile map will be associated with an authentication map. When a user is logged in through a authentication map, the profile is updated with the values in the corresponding user profile map. All the information that populates the user profile comes from the user profile map. You can specify the role, languageCD, description, and so on in the user profile map.

The user ID of the profile that the systems creates corresponds to the User Profile Map - User ID Attribute field, which contains an LDAP attribute name.

Consider an entry corresponding to the user sramdass in LDAP:

dn: uid=sramdass, dc=peoplesoft, dc=com cn: sramdass uid: sramdass123 description: peoplesoft user mail: sramdass@oracle.com telephone: 12345678 objectclass: person password: PASSWORD

Example 1

Authentication Map Search Attribute: cn

User Profile Map User ID Attribute:mail

You must log in as sramdass/PASSWORD, while the system creates the user profile with the name sramdass@oracle.com.

Example 2

Authentication Map Search Attribute: uid

User Profile Map User ID Attribute:telephone

You must log in as sramdass123/PASSWORD while the system creates the user profile with the name 12345678.

Note.

The Search Attribute value in the authentication map and the User ID Attribute value in the user profile map need not be the same.

Click to jump to parent topicCreating Role Membership Rules

Use the Role Policy page to define the rules that are read by Dynamic Role Rule PeopleCode and populate PeopleSoft roles with members. The rules return the DNs of "people" directory entries, which supply the system with the user IDs specified on the user profile mapping.

This section provides an overview of role membership rules and discusses how to define role membership rules.

Click to jump to top of pageClick to jump to parent topicUnderstanding Role Membership Rules

PeopleSoft security roles are comparable to LDAP directory groups. Roles enable you to group user IDs in logical sets that share the same security privileges. PeopleSoft enables you to keep your external directory groups synchronized with the data stored within the PeopleSoft database.

Important! You must keep the data within PeopleSoft consistent with any changes made to the structure or content of the external directory server, especially when you are dealing with security data. The Role Membership Rules page enables you to modify a PeopleSoft role based on directory criteria.

Click to jump to top of pageClick to jump to parent topicPage Used to Create Role Membership Rules

Page Name

Definition Name

Navigation

Usage

Role Policy

DSSECROLERULE

PeopleTools, Security, Directory, Role Membership Rules

Define the rules that are read by Dynamic Role Rule PeopleCode and populate PeopleSoft roles with members.

Click to jump to top of pageClick to jump to parent topicDefining Role Membership Rules

Access the Role Policy page (PeopleTools, Security, Directory, Role Membership Rules).

Rule Name

Displays the directory search name that you entered on the search page.

Description

Enter a short description of the rule.

User Profile Map

Select the user profile map to associate with the rule.

Directory ID

Displays the directory associated with the user profile map that you select.

Assign to Role

Click this link to automatically start the Dynamic Members page in the Roles component of the Security menu. On that page, select Directory Rule Enabled and specify the server on which to carry out the rule.

Directory Search Parameters

Search Base

Enter the entry (or container) at which to begin the search.

Search Scope

Select the search scope for this search from the following options:

Base: The query searches only the value in the Search Base field.

One: The query searches only the entries one level down from the value in the Search Base field.

Sub: The query searches the value in the Search Base field and all entries beneath it.

Build Filter

( )

Parentheses; on either side of the filter expression select the check boxes below the parentheses to group expressions.

Attribute

Select the attribute that the system will filter.

Operation

Assign an operator to your rule, such as <, <=, <>, =, >, or >=.

Value

Enter the value to assign to the attribute that you specified.

And/Or

To add another line to your rule, select AND or OR, depending on your rule logic. Select END to signify the end of the search. Select NONE if you are not using this kind of filter.

Refresh Search Filter

After you make changes using the Build Filter options, click this button to update the Search Filter edit box to reflect the changes.

Clear Search Filter

Click this button to delete all values from the Search Filter edit box and the Build Filter selections.

Search Filter

The purpose of this field depends on whether you also specify values in the Directory Attribute field, as follows:

  • No directory attributes specified.

    Enter a name=value pair that identifies a key field and value on the user record. The system applies this criterion to search for an individual user, regardless of group membership.

  • One or more directory attributes specified.

    Enter a name=value pair that the system applies to the search for the DN of the defined container or group. This value typically displays the directory object class of the container in the form “objectclass = GroupOfUniqueNames”, for example. This indicates what type of container to search. To retrieve the correct container DNs, the system adds the name of the container to the search filter at runtime.

Search Attributes

Directory Attribute

Select attributes that identify the user to add to this membership. The system searches only for members within the group that is specified by the Search Filter field.

Note. You can also write PeopleCode to determine group membership using any arbitrary LDAP search criteria.

Click to jump to parent topicDeleting Directory Configurations

You can delete the entire directory configuration or just parts of it.

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicPage Used to Delete Directory Configurations

Page Name

Definition Name

Navigation

Usage

Delete Directory

DSPURGEDIRID

PeopleTools, Security, Directory, Delete Directory Configuration

Delete the entire directory configuration or just parts of it.

Click to jump to top of pageClick to jump to parent topicDeleting the Directory Configuration

Access the Delete Directory page (PeopleTools, Security, Directory, Delete Directory Configuration).

Delete Associated Maps

Deletes the authentication and user profile maps from the configuration.

Delete Associated Searches

Deletes any searches related to the directory configuration.

Delete Associated Role Rules

Deletes any role rules that you have specified for a configuration.

Delete Associated Entry Rules

Applies to the PeopleSoft Directory Interface product only.

Delete Directory Configuration

After you have made the appropriate choices, click this button to perform the delete process. If you click this button with nothing selected, the system deletes only the directory ID and leaves all of the other configuration information intact.

Click to jump to top of pageClick to jump to parent topicWorking with the Workflow Address Book

Access the Address Book page (PeopleTools, Security, Directory, Workflow Address Book).

Use the Address Book page for configuring LDAP address lookups for use with user-initiated notifications in PeopleSoft Workflow. This page contains the controls needed to retrieve the necessary addresses from the directory. This page applies only if you store user information in a directory.

Map Name

Displays the name of the workflow address book map.

Status

Select Active or Inactive.

Connect & Search Info

Directory ID

Select the directory ID of the directory that you intend to use for authentication.

Anonymous Bind

If all directory data required for authentication and user profile maintenance is visible to an anonymous connection, select this check box.

Use Secure Socket Layer

Select this option if you are implementing an SSL connection between PeopleSoft and the directory.

Distinguished Name

Enter the DN associated with the directory ID where you want to start the workflow address book search.

Search Base

Enter the root of the directory information tree under which the system should search for user information.

Search Scope

Select the search scope for this search. Values are:

Base: Not applicable. You should not use Base on the authentication map.

One: The query searches only the entries one level down from the entry in the Search Base field.

Sub: The query searches the entire sub tree beneath the search base entry.

Search Limit

Enter the maximum number of search results to return. The maximum is 99999.

Attribute Info

Display Name Attribute

Select the attribute to associate to the display name in the workflow address book.

Email Attribute

Select the attribute to associate to the email in the workflow address book.

User ID Attribute

Select the attribute to associate to the user ID in the workflow address book.

Group Object Class

Select the attribute to associate to the group object class in the workflow address book.

Member Attribute

Select the attribute to associate to the member attribute in the workflow address book.

See Also

Adding Events and Routings

Click to jump to parent topicEnabling Signon PeopleCode for LDAP Authentication

Access the Signon PeopleCode page (PeopleTools, Security, Security Objects, Signon PeopleCode).

LDAP Authentication runs as Signon PeopleCode that must be enabled and configured to be carried out with proper permissions.

To enable Signon PeopleCode:

  1. Click the Invoke As option that applies to your configuration.

    Do you want to use a default user ID, or do you want the Signon PeopleCode to be invoked by the user ID of the user who happens to be signing on to the system? Either way, the value for the user ID and password must be a valid PeopleSoft User ID and password. For LDAP authentication, you need to use Invoke As, because the user signing in (most likely) does not exist in the local system until Signon PeopleCode runs and updates the local cache of user profiles.

    Note. The user ID entered, whether it is Invoke As user signing in or a default user, must be able to access the User Profiles component in a permission list.

  2. Locate the row for the LDAP_Authentication function on the Record FUNCLIB_LDAP.

  3. Select the Enabled check box (if it is not already selected by default).

  4. Ensure that the Exec Auth Fail check box is selected; if PeopleSoft authorization fails, then Signon PeopleCode is carried out.

    PeopleSoft authorization always fails if you are using LDAP authentication.

  5. Click Save at the bottom of the page.

  6. Reboot any application servers running against the local database.

Note. If you intend to use the User Profile Map, you also need to enable LDAP_PROFILESYNCH. The same options apply.

Click to jump to parent topicUsing LDAP Over SSL (LDAPS)

This section provides an overview of SSL and discusses SSL between PeopleSoft and LDAP.

Click to jump to top of pageClick to jump to parent topicUnderstanding SSL

SSL is a protocol developed by Netscape that defines an interface for data encryption between network nodes. To establish an SSL-encrypted connection, the nodes must complete the SSL handshake. These are the simplified steps of the SSL handshake:

  1. Client sends a request to connect.

  2. Server responds to the connect request and sends a signed certificate.

  3. Client verifies that the certificate signer is in its acceptable certificate authority (CA) list.

  4. 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).

  5. Server uses its private key to decrypt the client generated session key.

Establishing an SSL connection requires two certificates: one containing the public key of the server (server certificate or public key certificate) and another to verify the CA 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 connection, and the client needs to be configured with the trusted root certificate of the CA 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 is a lower level protocol than the application protocol, such as HTTP or LDAP. SSL works the same regardless of the application protocol. To connect to a Directory server over LDAPS from a PeopleSoft application, SSL has to be configured in Directory server and PeopleSoft application.

Note. Establishing LDAPS is not related to web server certificates or certificates used with PeopleSoft integration.

Click to jump to top of pageClick to jump to parent topicSSL Between PeopleSoft and LDAP

You can use LDAP Business Interlink to establish a secure LDAP connection between the application server and the LDAP server. To establish the secure connection between the PeopleSoft application server and the LDAP server you will need the following certificates:

Installing and Removing Root CA Certificates in PeopleSoft Databases

To install Root CA Certificates into PeopleSoft databases:

  1. Navigate to PeopleTools, Security, Digital Certificates.

    The list of installed certificates appears.

  2. Click the + (plus sign) button in the last row of the displayed certificates.

    A blank row appears.

  3. Select Root CA from the Type drop-down list box.

  4. Enter a meaningful name as the alias of this certificate in the Alias field.

  5. Click the Issuer Alias field prompt button.

    The name of the Alias automatically populates the Issuer Alias field.

  6. Click the Add Root link.

    The Add Root Certificate page appears. Minimize the browser window.

  7. Open the root CA certificate with a text editor and copy the contents.

  8. Maximize the browser and paste the contents into the text box.

  9. Click the OK button to see the new digital certificate.

  10. Reboot the application server.

To remove Root CA Certificates from PeopleSoft databases:

  1. Navigate to PeopleTools, Security, Digital Certificates.

    The list of installed certificates appears.

  2. Click the – (minus sign) button in the row of the certificate you want to remove.

    A Delete Confirmation message box appears.

  3. Click the OK button to confirm the deletion.

  4. Reboot the application server.

Enabling LDAP Authentication Over SSL in PeopleSoft Applications

To enable LDAP authentication over SSL in PeopleSoft applications:

  1. Follow the documentation for your directory server to add the Server Certificate to your directory server.

  2. Install the Root CA certificate into the PeopleSoft database.

    See

  3. Select PeopleTools, Security, Directory, Configure Directory, Directory Setup to access the Directory Setup page.

    The SSL Port field must reflect the correct LDAPS port for the directory server.

  4. Click the Test Connectivity tab.

    You must see SUCCESS for the SSL transactions to work. If you see FAILURE here, the LDAP authentication will not succeed over SSL.

  5. Select PeopleTools, Security, Directory, Authentication Map to access the Authentication Map page, and select the Use Secure Sockets Layer check box.

  6. Enable the LDAP_AUTHENTICATION signon PeopleCode.

    See Enabling Signon PeopleCode.

  7. Reboot the application server.

Click to jump to parent topicViewing SSL for LDAP Transactions Setup Examples

For the LDAP transactions between PeopleSoft and a directory server, SSL must be configured in both PeopleSoft and the directory server. This section provides a sample SSL configuration between directory servers such as Oracle Internet Directory, Active Directory Server, Sunone, and PeopleSoft applications.

Important! The procedures outlined in this section are provided as examples. They may not necessarily apply to all situations. Verify the appropriate documentation for further details.

Click to jump to top of pageClick to jump to parent topicSetting Up SSL for Oracle Internet Directory (OID)

To set up SSL for OID:

  1. Create certificate request in the wallet.

  2. Create a new configuration set for SSL in Oracle Directory Manager.

  3. Configure OID with the newly created configuration set.

Creating the Certificate Request in the Wallet

To create the certificate request:

  1. Open Oracle Wallet Manager and select Operations, Add Certificate Request.

  2. Fill in the fields and click the OK button.

  3. Select Wallet, Save. (By default, it is stored in C:\Wallets.)

Creating a New Configuration Set for SSL in Oracle Directory Manager

To create a new configuration set for SSL in Oracle Directory Manager:

  1. Open the Oracle Directory Manager and log in as an admin.

  2. From the Server management section on the left pane, select the Default Configuration Set.

    The Default Configuration Set properties appear in the right pane.

  3. From the tool bar, click the Create Like icon.

    A new configuration set will be created.

  4. In this new configuration set, change these properties:

    Number of Child Processes = 4

    Non SSL Port = <Any number other than 389>. For example, 399.

  5. Click the SSL Settings tab and enter the following values:

    SSL Authentication = SSL Server Authentication.

    SSL Enable = Both SSL and Non SSL.

    SSL Wallet = <path of the Wallet>. For example, file:C:\wallets.

    SSL Port = <any number other than 636>. For example, 646.

Note. The port numbers for both SSL and non-SSL can be changed to any values other than the default configuration set port values.

Configuring OID with the Newly Created Configuration Set

To configure OID with the newly created configuration set:

  1. Restart the oidldapd server by navigating to <Oracle_Home>\ldap\admin and running the following commands in the command prompt:

    oidctl connect=<database SID> server=<OID server type value> instance=<instance number value> stop

    Example: oidctl connect=orcl server=oidldapd instance=1 stop

  2. Start the OID with the new configuration set (configset=1). The default configuration set is demoted (configset=0).

    oidctl connect=<database SID> server=<OID server type value> instance=<instance number value> configset=<new configset value> start

    Example: oidctl connect=orcl server=oidldapd instance=1 configset=1 start

  3. Close the Oracle Directory Manager and log in through SSL.

    Enter the wallet path and the wallet password in the login dialog.

    Note. If the SSL is incorrectly configured, you will not be able to log in.

    The wallet path should be given as file:C:\wallets. The path of the wallet is sufficient; the wallet name is unnecessary.

Click to jump to top of pageClick to jump to parent topicSetting up SSL for Active Directory Server

Any utility or application that creates a valid PKCS #10 request can be used to form the SSL certificate request. The following example uses certreq.exe to form the request.

To set up SSL for Active Directory Server (ADS):

  1. Find the Fully Qualified Domain Name (FQDN).

  2. Request a server authentication certificate.

  3. Verify an LDAPS connection.

To create certificate request, the Fully Qualified Domain Name (FQDN) of the Domain Controller (DC) is needed.

Finding the FQDN

To find the FQDN:

  1. Select Start, Programs, Administrative Tools, DNS.

    The dnsmgmt window opens.

  2. Double-click the host name of your machine, and you will see the FQDN.

Requesting a Server Authentication Certificate

To request a server authentication certificate:

  1. Copy and paste the following text into a new text file and save it as request.inf:

    ; ----------------- request.inf ----------------- [Version] Signature="$Windows NT$" [NewRequest] Subject = "CN = LAB-SUMAHADE-WF.adserver.coretools” ; replace with the FQDN of the DC KeySpec = 1 KeyLength = 1024 ; Can be 1024, 2048, 4096, 8192, or 16384. ; Larger key sizes are more secure, but have ; a greater impact on performance. Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication ;-----------------------------------------------

  2. Provide the fully qualified DNS name of the domain controller in the request. The semicolon (;) is used to indicate that the following text through the end of the line is a comment.

  3. Create the request file and then, in a command prompt, navigate to the path where the request is and type the following command:

    certreq -new <Name of the inf file> <name of the request file>

    Example: certreq -new request.inf request.req

    A new request.req is created in the current directory. This is the base64-encoded request file.

  4. Submit the request to a CA for a server certificate. Save the server certificate, servercert.cer, on your machine. The saved certificate must be base64–encoded.

  5. Accept the issued certificate by opening a command prompt, navigating to the path where the server certificate is stored, and executing the following command:

    certreq -accept <Name of the server certificate>

    Example: certreq -accept servercert.cer

  6. Now the certificate is installed in your personal store. A private key is associated with this certificate. Verify this key by referring to the ADS documentation.

  7. Restart the domain controller by restarting the server.

Verifying an LDAPS Connection

To verify an LDAPS connection:

  1. Start the Active Directory Administration Tool (ldp.exe) by selecting Start, Run, ldp.exe.

  2. On the Connection menu, click Connect.

  3. When prompted, enter the name of the domain controller (enter the FQDN) to which you want to connect and the SSL port number.

  4. Click OK.

    The RootDSE information should appear in the right pane, indicating a successful connection.

Click to jump to top of pageClick to jump to parent topicSetting up SSL for Sunone Directory Server (iPlanet)

 

  1. Open the Sunone Directory Server console and select Manage Certificates from the Tasks tab.

  2. Select Request and then Next.

  3. Enter your computer name (or server name) and other organizational details.

  4. Enter a password and click Next.

    The system creates a certificate request.

  5. Click the Copy to Clipboard button to copy this request to the clipboard, or save the request to a file.

  6. Submit the Certificate Request to a trusted CA and download the server certificate, for example, servercert.cer.

  7. In the directory server, open the Manage Certificates page.

  8. On the Server Certs tab, click the Install button.

  9. Select this local file. Click the Browse button and select the server certificate, servercert.cer. Click Next on each of the following two pages.

  10. Enter a name and a password and then click Done.

Click to jump to top of pageClick to jump to parent topicSetting Up SSL in PeopleSoft Applications

This section discusses how to configure the LDAP business interlink to establish SSL encrypted LDAP connections. The LDAP business interlink uses a root CA certificate that you install in the PeopleSoft database through the Digital Certificates page.

To enable SSL, the SSL parameter in the LDAP business interlink should be set to YES either:

Programmatically through PeopleCode.

Manually in Application Designer.

Setting the Business Interlink SSL Parameter in Application Designer

To set the SSL parameter in Application Designer:

  1. Open an existing instance of the LDAP business interlink, or create a new instance.

  2. Select the Settings tab.

  3. Set the SSL parameter to YES.

  4. Save the business interlink.

This example shows the correct setting of the SSL parameter for the LDAP_ADD business interlink:

Note. This example shows the LDAP_ADD business interlink transaction, but it applies to all LDAP business interlink transactions.

Setting the Business Interlink SSL Parameter Programmatically

To set the business interlink SSL parameter programmatically:

  1. Drag the business interlink definition into the PeopleCode editor. The following code is created:

    /* ===> This is a dynamically generated PeopleCode template to be used only as a helper to the application developer. You need to replace all references to ’<*>’ OR default values with references to PeopleCode variables and/or a Rec.Fields.*/ /* ===> Declare and instantiate: */ Local Interlink &LDAP_SEARCH_1; Local BIDocs &inDoc; Local BIDocs &outDoc; Local boolean &RSLT; Local number &EXECRSLT; &LDAP_SEARCH_1 = GetInterlink(INTERLINK.LDAP_SEARCH); /* ===> You can use the following assignments to set the configuration parameters. */ &LDAP_SEARCH_1.SSL = "NO"; &LDAP_SEARCH_1.SSL_DB = "cert7.db"; &LDAP_SEARCH_1.URL = file://psio_dir.dll"; &LDAP_SEARCH_1.BIDocValidating = "Off"; ...

    Note. This example uses the search transaction, but the principle applies to any transaction.

  2. Change the SSL setting to indicate that SSL should be used. For example: &LDAP_SEARCH_1.SSL = "YES";

Note these points: