Understanding the Delivered External Authentication Solutions

PeopleSoft delivers the most common authentication solutions and packages them with our application for you to use. This saves you the trouble of developing your own solutions and saves you time with your security implementation.

Note: The traditional method, where the user submits signon credentials that the system compares to a row in the PSOPRDEFN table, is a valid means of authentication; however, it is not a recommended method for increased scalability and manageability as you deploy applications to the internet.

The authentication solutions are delivered PeopleCode programs that you can include in your Signon PeopleCode. The following table describes each function that appears on the Signon PeopleCode page:

Function

Exec Auth Fail

Description

WWW_Authentication

Not Required

Applies when you want the browser to pass the client certificate to the web server for authentication by mutual authentication Secure Sockets Layer/Transport Layer Security (SSL/TLS) at the web server level (also known as client authentication). In this situation, you configure PeopleSoft to "trust" the authentication performed by a third-party system at the web server.

The function performs the following:

  1. Extracts the user’s distinguished name (DN) from the client certificate passed to the application server by the HTTP server.

  2. Sets a global variable to the DN for a subsequent call to the LDAP_ProfileSynch function.

  3. Converts the DN to a PeopleSoft user ID and sets the current user context.

LDAP_Authentication

Required

Applies when you want the user to submit signon credentials at the signon page, and then the system passes the credentials to the directory to perform authentication.

This function performs the following:

  1. Searches the directory for all entries that match the entered user name.

  2. Attempts to bind to the directory for each found DN using the entered password.

  3. Sets a global variable to the bound DN for a subsequent call to LDAP_ProfileSynch.

  4. Converts the DN to the appropriate PeopleSoft Username and sets the current user context.

SSO_Authentication

Not Required

Applies in situations where you have single signon configured. The system authenticates the user's single signon token, which has already been issued by another database (node).

This function performs the following:

  1. Converts the PeopleSoft User ID to a DN.

  2. Sets a global variable for a subsequent call to LDAP_ProfileSynch.

LDAP_ProfileSynch

Not Required

Applies in situations where PeopleSoft user profiles need to be created or updated with data stored in an LDAP directory. The function requires that the global variable &global_DN has been initialized by one of the previous authentication functions.

Remember that regardless of how a user is authenticated, each user populates a row in PSOPRDEFN to which applications can refer during transactions (if necessary). The LDAP_ProfileSynch updates that row in PSOPRDEFN (or user profile cache) with the most current information.

As delivered, this function performs the following:

  1. Retrieves the LDAP entry specified by &global_DN.

  2. Either creates or updates the corresponding PeopleSoft user profile.

Note: One of the XXX_Authentication functions needs to be carried out prior to running LDAP_ProfileSynch.

PeopleSoft provides disabled example Signon PeopleCode with this function. If you work with the NDS, Active Planet, or iPlanet directories, you can use this Signon PeopleCode to assign roles dynamically at sign-on time.

See LDAP_ProfileSynch Considerations.

When using any of the delivered external authentication solutions, the following items apply:

  • All functions get the LDAP server configuration from specifications in PeopleTools > Security > Directory > Configure Directory.

  • All functions support a single database—multiple databases are not required.

This section discusses:

  • WWW_Authentication considerations.

  • LDAP_Authentication considerations.

  • SSO_Authentication considerations.

  • LDAP_ProfileSynch considerations.

If you intend to authenticate your users at the web server level using mutual authentication SSL/TLS (also known as client authentication), the users that are authenticated at the web server level must signon to the system using a different web site than users of the other authentication methods.

When you configure a PeopleSoft site to enable public access, a public user ID and password in the web profile provide automatic authentication. Keep in mind that this enables public access for the entire site. The web server always passes the specified public user ID and password to the application server. So, if you want some users to be authenticated by PeopleSoft rather than at the web server level, they must sign in through a PeopleSoft site that has public access disabled.

Important! The PeopleCode RevalidatePassword( ) and SwitchUser( ) built-in functions don't work during a user session for which you're using WWW_Authentication.

In WWW_Authentication, PeopleSoft performs no validation of users and their passwords. The Signon PeopleCode simply accepts the web server's word that the user was properly authenticated. Your PeopleSoft application has no way to revalidate the user's password in this case, so you shouldn't call RevalidatePassword or SwitchUser after WWW_Authentication has been used.

You can determine whether WWW_Authentication has been used by examining a global variable. The Signon PeopleCode for WWW_Authentication sets the PeopleCode global variable called &authMethod to the value WWW when a successful signon occurs. In PeopleCode where you want to call RevalidatePassword or SwitchUser, first examine &authMethod. If it's not equal to WWW, you can call those functions.

When using LDAP_Authentication, the default searching behavior can be overridden by entering attribute=%UserId% in the Search Attribute edit box on the Directory Setup page. When you insert this syntax, the system constructs the DN of the user by concatenating the search attribute plus the entered user name with the search base.

For example, given the setup depicted in the following example, if the user entered Sschumacher in the User Name edit box of the signon page, the DN would be: 

uid=Sschumacher,ou=Inkoop,o=ccb.com

This constructed DN would be used for the bind attempt rather than searching the directory with the search filter of:

uid=Sschumacher

If you are using SSO_Authentication and LDAP_ProfileSynch to automatically generate profiles, then the value of the LDAP attribute mapped to User ID must be unique throughout the directory.

The PeopleSoft User ID uniquely identifies a person within PeopleSoft, and a DN uniquely identifies a person within the directory. PeopleSoft maps the PeopleSoft User Profile to a directory entry by specifying the directory attribute that holds the value of the PeopleSoft User ID.

You specify the appropriate mapping between the PeopleSoft system and your directory using the User Profile Caching component. On the Mandatory User Properties page, you must equate the PeopleSoft User ID attribute with an LDAP attribute. For example, in many cases the PeopleSoft User ID is mapped to the LDAP attribute of uid.

With a single signon token, the system can provide the Signon PeopleCode with only a user ID value to identify a person. Then the system must search the directory to find the corresponding DN. If multiple entries within the scope of the search have the same value on the User ID attribute, then PeopleSoft is unable to determine which entry corresponds to the user.

Note: It is not required to use these functions to enable single-signon within PeopleSoft. The SSO_ Authentication combined with the LDAP_ProfileSynch applies only to situations where you want cache profile data from a directory if the user presents a single-signon token during signon.

If you work with the NDS, Active Directory, or iPlanet directories and would like to assign roles dynamically at sign-on time, you can use the disabled example Signon PeopleCode that PeopleSoft has provided with this function. Directory-specific information is included in the comments of the code.

Note: This Signon PeopleCode provides a basic framework for dynamically assigning roles at sign-on time. If you want to dynamically assign roles at sign-on time, you must modify this code to work specifically with your NDS, Active Directory, or iPlanet directory schema. You should attempt this only if you are familiar with your directory schema and with writing PeopleCode.