1. USM Regional PeopleSoft Conference
PeopleSoft Directory
Interface for HRMS
prepared for
USM Regional PeopleSoft Conference
June 10, 2005
Hank Kehlbeck,
Sr. Product Manager, HCM Strategy
Introduce yourself. Thank people for attending. Ask who has implemented LDAP, what version – who’s planning to implement.
Ask how many know what LDAP, how many functional, how many technical.

2. PeopleSoft Directory Interface Overview
Agenda
LDAP Overview
PeopleSoft Directory Interface Overview
Delivered Templates
Configuring Directory Interface
Where to Get More Information
Lessons Learned / Your Feedback

3. LDAP Overview

4. What is LDAP? Lightweight Directory Access Protocol
Standard protocol for reading from and writing to directories
Common language that LDAP clients and servers use to communicate with each other
Accesses directory information usually organized in a tree-like structure
LDAP was designed at the University of Michigan to adapt a complex enterprise directory system (called X.500) to the modern Internet. A directory server runs on a host computer on the Internet, and various client programs that understand the protocol can log into the server and look up entries. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service "for the rest of us.“
LDAP servers exist at three levels: There are big public servers such as BigFoot and Infospace, large organizational servers at universities and corporations, and smaller LDAP servers for workgroups.
You probably already have an LDAP-aware client installed on your computer. Most modern clients are set up to search an LDAP directory for addresses. These include Outlook, OS X Mail, Eudora, Netscape, QuickMail Pro, and Mulberry.
LDAP has broader applications, such as looking up services and devices on the Internet (and intranets). Netscape Communicator can store user preferences and bookmarks on an LDAP server. There is even a plan for linking all LDAP servers into a worldwide hierarchy, all searchable from your client.
LDAP promises to save users and administrators time and frustration, making it easy for everyone to connect with people without frustrating searches for addresses and other trivia.

5. What are the Benefits? Hierarchical and specialized Database
Scalable, Flexible, Extensible
Efficient Means of Organizing/Retrieving Information
High Query (Read) Performance
Poor Update (Write) Performance
LDAP should eventually make it possible for any application running on virtually any computer platform to obtain directory information, such as addresses and public keys.
LDAP directory entries feature a hierarchical structure that reflects political, geographic, and/or organizational boundaries. In the original X.500 model, entries representing countries appear at the top of the tree; below them come entries representing states or national organizations. Typical LDAP deployments use DNS names for structuring the top levels of the hierarchy. Further below might appear entries representing people, organizational units, printers, documents, or just about anything else.
LDAP has influenced subsequent Internet protocols, including later versions of X.500, Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML) and the Service Location Protocol.
An organization normally uses their DNS domain name as the root entry for their local LDAP tree. For example, oracle.com is free to use dc=oracle,dc=com. The dc stands for domainComponent. Ou stands for organizational unit and cn stands for common name. An LDAP directory
Each node of the tree is called an "LDAP entry", and can contain multiple attributes in the form of attributeType=value pairs, for example surname=Wiesel.
One attributeType may appear multiple times, in effect having multiple values.
One or more of the attributes are chosen as a Relative Distinguished Name, and will be used to identify the node based on its parent. This means the RDN must be unique among the children of its parent. Listing all the RDNs, separated by commas, from the node to the root, gives us the Distinguished Name of the entry.
The RDN of the entry for John Wookey is cn=John Wookey. We could also use user id (uid) so long as the DN is unique)
The DN in this example is: cn=John Wookey,ou=Development,dc=oracle,dc=com.

6. LDAP Distinguished Names
dc=oracle
dc=com
c=US
c=FRA
ou=Tools
ou=HRMS
ou=HRMS
An LDAP directory entry consists of a collection of attributes and is referenced unambiguously with a name, called a distinguished name (DN). For example, a DN might be the value “uid=jsmith,ou=Tools,c=US,dc=oracle,dc=com". Each of the entry's attributes are defined as part of an object class and are grouped together into schemas; those schemas for representing individual people within organizations are termed white pages schema.
Each entry in the database is associated with one or more these object classes, which define whether an attribute is optional or mandatory, and what type of information it stores. The attribute names are typically mnemonic strings, like "cn" for common name, or “uid" for user id.
A DN is a string of attributes which uniquely identifies an entry in the directory
Typical LDAP deployments use DNS names for structuring the top levels of the hierarchy. Further below might appear entries representing people, organizational units, printers, documents, or just about anything else.
So, in this example, we have a representation of a partial LDAP schema which includes Tools and HRMS development organizations in US and France and a single user id: jsmith.
uid=jsmith
Dn: uid=jsmith,ou=Tools,c=US,dc=oracle,dc=com

7. Directory Interface: Overview
So how does PeopleSoft interface to an external, hierarchically structured schema like this?

8. What is Directory Interface?
PeopleSoft
Database
Directory
Directory Interface
The information in your PeopleSoft is stored in tables according to the relational model. The information in your directory is stored in trees according to a hierarchical model. As such, you need to use the PeopleSoft directory interface to “map” selected PeopleSoft data to the appropriate corresponding data in the directory service. Using the mapping pages in PeopleSoft Directory Interface, you indicate the relationship between the PeopleSoft objects and the directory objects. When PeopleSoft Directory Interface receives user data from the PeopleSoft database, it uses this information to map the data objects to the corresponding objects in the directory.
PeopleSoft Directory Interface is a tool for integrating PeopleSoft data with Directories through LDAP. Starting with Tools 8.1, Peoplesoft provides for the integration of PeopleSoft security with LDAP directories to authenticate directory users. This allows PeopleSoft user’s credentials to be validated against the directory, hence leverageing pre-existing authentication data in an LDAP directory service and achieve single-sign-on across multiple PeopleSoft applications. Furthermore, user data that is typically used in an LDAP directory (name, , phone number) can be updated instantaneously or on batch interval when information changes in the PeopleSoft database.

9. Features and Benefits Flexible Centralized Information
Compliant w/any LDAPv3-Compliant Directory Server
Supports flat and hierarchical schemas
Real-time or batch updates to map data
Effective-dated
Centralized Information
Eliminate managing data in multiple locations
Enable single sign-on to enterprise applications
Audit data integrity b/w HCM and Directory Server
Lower Cost, Standards-based Security
Control access to PeopleSoft using LDAP
Reduce security maintenance costs
Lower Security Maintenance Costs. Customers can use a single, centralized user profile for
PeopleSoft and non-Peoplesoft applications. This provides reduced maintenance cost and
fewer errors because the user profile data isn’t manually managed in multiple places.
Improved User Experience. Embracing directory servers across the enterprise provides a
better user experience for your end users since they don’t have to remember multiple user
ID’s and passwords. Directory server integration also simplifies single signon processing
which means that your end users are not repeatedly prompted for their passwords as they
jump between systems.

10. Directory Interface Structure
The PDI is made of 3 layers of modules:
Application Template(s)
Directory Maps and all other Meta-Data, Schema Extensions
App. Messages, PeopleCode functions
Application /
Business
Level
Common Components
Mapping Function, Directory Load/Audit, Audit Report,
BI Status Report, Directory Search, Entry Membership Rules
PDI Core
Level
How is this mapping done?
PeopleSoft delivers three technologies that enable you to:
Authenticate against an LDAP V3 compliant directory server.
Reuse your existing User Profiles stored within LDAP.
The three technologies are:
Directory Business Interlink. At the infrastructure level, the Directory Business Interlink exposes the Lightweight Directory Access Protocol (LDAP) to PeopleCode. The system uses it for all communication with the LDAP server process running on a directory server.
User Profile Component Interface. The User Profile Component Interface exposes the User Profile Component to PeopleCode. The system uses it to programmatically manage a local cache of User Profiles.
Signon PeopleCode. Signon PeopleCode is PeopleCode that executes when a user signs on to the system—similar to the login scripting of most network systems. Signon PeopleCode uses the Directory Business Interlink and the User Profile Component Interface to verify directory-based credentials and programmatically create a local User Profiles cache.
PeopleTools
LDAP Business Interlinks, Configure Directory, Cache
Schema, LDAP User Authentication , Delete Directory
Infrastructure
Level

11. Directory Interface Components
Mapping Data and Templates
Optional directory schema extensions
Integration Tools
Fields, Records, PeopleCode, Application Messages,Business Interlinks
Audit reports
Signon PeopleCode for Directory Server Authentication.
A set of tools for mapping data from PeopleSoft applications to and from the directory server.
The templates that contain the mapping definitions for PeopleSoft 8 HRMS.
Optional directory schema extensions for PeopleSoft HRMS
The objects that are installed with PeopleSoft 8 HRMS that drives the directory integration.
These objects are primarily Fields, Records, PeopleCode Programs, Application Messages,
and Business Interlinks that allows you to update and upload the directory server data.
Audit reports that compares the data in your PeopleSoft system with what is in your directory
server.
Signon PeopleCode for directory server authentication.

12. Process Flow of an Update
1. HR Transaction
New Hire Data
2. Business Event Triggered
Application Server
3. App. Msg Published to Queue (if current)
App. Message Queue
http/html
<xml>
<xml>
4. App. Msg. Subscription Process Invoked
HRMS to Directory Maps
Here is overview of what happens in each of the steps.
·         A business event triggers a message. Business event could be a New hire or change to department.
·         The Messaging server removes the message from the publishing queue and determines where the message is to be sent by using the message routing rules. This sends the message to the relevant node
·         In this particular case the message is sent to the local Node (itself). The messaging server places the message on the Subscribing queue for the local Node
·         In the subscribing system the messaging server invokes the subscription People code
·         The Subscription people code takes the message from the subscription queue and calls the Directory Mapping function
·         The mapping function uses the message as input to the function. Using data stored in mapping tables, the function loads the message record/field names and constants into one of two arrays. One array is set up to load Attribute name and value combinations. The second array is used to construct the Distinguished Name (DN). Once the constants are loaded into the arrays, the Mapping function traverses the Message and loads the data for each Record/Field combination. These values are used either to construct the DN or to populate attribute values.
·         The audit action on the PSCAMA record in the message is used to determine what action is to be taken at the directory level
·         The mapping function uses data from the two arrays to construct an output message, which closely resembles the Business Interlink structure.
·         Using the output message and a configuration setting in mapping tables, the mapping function either writes the data directly to the Directory using Business Interlinks, writes the data to a temporary table, or writes the data to an LDAP file. In the picture below number 7 arrow pointing to the Directory would be where the Business Interlink comes into play.
LDAP
5. LDAP Business Interlink writes data to Directory, using Map Defns.

13. Directory Interface feature
The PDI Features (cont’d):
A “Massive” Directory Tree Re-organization:
BEFORE
AFTER
dc=oracle
dc=com
c=US
c=FRA
ou=HRMS
ou=Tools
uid=jsmith
dc=oracle
dc=com
c=US
c=FRA
ou=HRMS
ou=Tools
uid=jsmith
Automated massive Business-Event triggered Directory Tree Re-Orgs.

14. Supported LDAP Servers
LDAPv3-compliant Directory Servers:
Novell NDS eDirectory using any Novell supported O/S
Sun ONE Directory Server and higher using any Sun ONE supported O/S
Microsoft Active Directory on Windows 2000 Server
PeopleSoft currently supports the three leading directory server products:
Novell NDS eDirectory using any Novell supported O/S (no longer bundled in 8.9)
Sun ONE Directory Server (formerly iPlanet) using any Sun ONE supported O/S
Microsoft Active Directory on Windows 2000 Server and any LDAPv3-compliant Directory Servers

15. Directory Interface:
Delivered Templates

16. With 8.9, the goal was to adapt the Directory Interface to the new HCM Person Model and to consolidate HCM and Student Admin specific maps into one generic one.

17. Delivered Templates (8.9)
Directory Entry Map Name
Business Process
CS_ADVISOR_INSTR
Create a new Instructor
CS_APPLICANT
Create a new Applicant
CS_PERSON
Add a new Person ID
CS_STUDENT
Create a Student
HR_DEPARTMENT
Create a new Department
HR_LOCATION
Create a new Location
HR_PERSON
Add a new Person
With 8.9, the goal was to adapt the Directory Interface to the new HCM Person Model and to consolidate HCM and Student Admin specific maps into one generic one.

18. Delivered HR Mappings
dc=oracle
dc=com
Location Map
c=US
c=FRA
ou=Tools
ou=HRMS
ou=HRMS
Department Map
Example of how HR Maps correspond to LDAP DN entries
uid=jsmith
Person Map

19. Schema Extensions (8.9) Type Name Type Name Object Class psftLsStudent
psftLsCrPerson
psftLsPerson
Type
Name
Attribute Type
psftInstitution
psftPurposeCd
psftStaffID
psftCnstType
psftCareer
psftProgram
psftPlan
psftAdmitTerm
psftInstrType
psftProgStatus
You can extend the LDAP schema to include

20. Configuring Directory Interface

21. 1. Install Directory Interface
To confirm that the PeopleSoft Directory Interface is installed check for the following menu: Enterprise Components, Directory Interface

22. 2. Configure the Directory
Use the Directory Configurations component (PSDSSETUP) to define and configure the directory connection and LDAP server name.
The Test Connectivity page has to show the result as “Success” before you can proceed any further.

23. 3. Cache the Schema
Use 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 enables you to select names of Object Classes and Attribute Types when creating security maps.

24. 4. Create Authentication Maps and User Profile Maps
Use the Authentication page only if you are implementing directory authentication as opposed to storing authentication information in the PeopleSoft database. You create a mapping to the directory that the PeopleSoft system relies on for authenticating users.
If you are going to authenticate users with the directory server, a PeopleSoft User Profile is required. That is, a row is still required in PSOPRDEFN. In this context, you “cache” LDAP user information inside your PeopleSoft system. The properties that you specify in 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 onto the system and the Sign on PeopleCode executes, PeopleSoft creates a row for that user in the user definition table by retrieving the LDAP information and creating a local cache. Sign on PeopleCode maintains this row automatically; there is no need for any manual updates. 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, and these appear on the Optional User Properties page.
Note: For More Details refer to PeopleTools – Security PeopleBooks

25. 5. Create Sign-on PeopleCode
Create Default User
Edit configuration.properties
Write Sign-on PeopleCode
LDAP Authentication runs as Sign on PeopleCode that must be enabled and configured to execute with proper permissions
For more details refer to PeopleBooks – under the PeopleTools – Security section

26. 6. Set Up Directory Mappings
In this step, you map PeopleSoft data to the equivalent directory objects so that you can keep the data synchronized. For HRMS, PSFT Delivers Templates for Person, Dept. Location. These provide a good starting point
Note: This is a very important step in the PDI/Directory interface as it shows us how to tie in the PDI information with the Directory Information. Refer to the Introduction to Directory Interface Peoplebooks for more details. This can be found under HRMS 8.8. – Enterprise Components Peoplebooks.
PeopleSoft Directory Interface receives PeopleSoft data from application messages published whenever there’s a business event associated with the messages identified in the Directory Mapping component. Each message contains information about records and the most recent data for the record fields. Using the mapping information that you set up in this step, PeopleSoft Directory Interface associates the fields in the message to the attributes in the directory and then updates the selected directory attributes with the field data from the message

27. 7. Define Roles and Memberships
Use the Role Policy (PeopleTools -> Directory -> Security) page to define the rules that are read by Dynamic Role Rule PeopleCode and populate PeopleSoft roles with members from the LDAP Directory. The rules return the DNs of "people" directory entries, which supply the system with the user IDs specified on the user profile mapping.

28. 8. Activate Message Channel
Activate the directory interface message channel

29. 9. Define Node
A relevant Node has to be defined and made active. This node should be the default local node. The node name is customer specific.

30. 10. Define/Activate Transactions
Note: This is an important step of linking business events with the PDI. For example in case of HR the act of activating messages like DSPERSONxxxx will lead to these messages being published when a transaction is entered in HR Personal Information (provided all the previous steps have been completed).

31. 11. Load PS Data into Directory
The Directory Load process is designed to be used when there is no existing data in the directory. It overwrites any data in the directory. If you do have data in your directory, we recommend that you use the Directory Audit process instead of the Directory Load process. The audit process compares the PeopleSoft data to your existing directory data and enables you to review and resolve any possible conflicts.
Note. For HRMS customers only, there is an alternative process named DSMAPINPUT FullSync that you can use in place of the Directory Load process. Our internal testing demonstrates that DSMAPINPUT FullSync loads employees and their job data into the directory with significantly improved performance. This new process does not replace the Directory Load process; it is provided as an alternative to load the data if performance becomes an issue. This process is documented in the PeopleSoft HRMS PeopleBooks.

32. 12. Audit / Search Directory
Use the Directory Search Component to define search parameters to query the directory and view the results. The search parameters that you set up on the Execute Search page can be saved for future use so you don’t have to enter them again. Search results are displayed on the Search Results page as they appear in the directory.

33. Where to Get More Information

34. PeopleBooks Security > Incorporating LDAP Directory Services
PeopleSoft Enterprise Components for PeopleSoft Enterprise HRMS and Campus Solutions 8.9 PeopleBook > Using PeopleSoft Directory Interface

35. Lessons Learned / Feedback

36. Q
&
Q U E S T I O N S
A N S W E R S A

37. Hank Kehlbeck
Senior Product Manager, HCM Strategy