Employing Signon PeopleCode and User Exits

This chapter provides an overview of the delivered external authentication solutions and discusses how to:

• Use Signon PeopleCode.

• Use the web server security exit.

• Use the Windows security exit.

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:

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.

WWW_Authentication 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.

See Also

RevalidatePassword

LDAP_Authentication Considerations

When using LDAP_Authentication, the default searching behavior can be overridden by entering attribute=%UserId% in the Search Attribute edit box on the In 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

SSO_Authentication Considerations

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.

LDAP_ProfileSynch Considerations

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.

Using Signon PeopleCode

This section provides overviews of Signon PeopleCode and Signon PeopleCode permissions, and discusses how to:

• Modify Signon PeopleCode.

• Enable Signon PeopleCode.

• Access X.509 certificates.

Understanding Signon PeopleCode

Signon PeopleCode runs whenever a user signs in to a PeopleSoft application. The main purpose of Signon PeopleCode is to copy user profile data from a directory server to the local database whenever a user signs in. This ensures that the local database has a current copy of the user profile. Because Signon PeopleCode runs at each signon, you are not required to maintain the local copy of the user information.

Signon PeopleCode is not limited to Lightweight Directory Access Protocol (LDAP) integration. You can also use Signon PeopleCode and business interlinks to synchronize a local copy of the user profile with any data source when a user signs in. Because the signon program is written in PeopleCode, you can customize it any way that suits your site requirements.

The basic process flow of Signon PeopleCode is as follows:

1. A user enters user ID and password on the signon page.

2. PeopleTools attempts to authenticate a user with the local PeopleSoft password.

3. Signon PeopleCode runs.

   It verifies the user and password, and then updates the local cache of user profiles stored in the PeopleSoft database.

Signon PeopleCode runs only when a user is logging through Pure Internet Architecture, the portal, or a three-tier Windows workstation.

Note. If you are using LDAP authentication, the PeopleSoft authentication process will fail because the user password is not stored within the PeopleSoft database. Because of this, if you are using LDAP authentication, you set your Signon PeopleCode program to run when PeopleSoft authentication fails.

Understanding Signon PeopleCode Permissions

Signon PeopleCode scripts run with full permissions of the user they’re invoked as. This includes access to the database using Structured Query Language (SQL), access to the file system, business interlinks, component interfaces application messaging, and so on. A developer could conceivably write a Signon PeopleCode program that exposed or corrupted sensitive information. To minimize this risk, you should follow these guidelines:

• You should limit access to the Signon PeopleCode setup page to trusted administrators only.

  This will prevent people from configuring un-trusted PeopleCode programs to run at sign-on time.

• If you aren’t implementing external authentication at your site (all your users are authenticated based on an existing user ID and password with the PeopleSoft database), you should not have the “Exec Auth Fail” column selected for any Signon PeopleCode scripts.

• After a trusted administrator configures the list of functions that should run at sign-on time, you should use Object Security to restrict access to the record objects that contain the programs.

  Only trusted developers should be allowed to modify the PeopleCode on these records.

• Even for trusted developers, it is a good idea to have a second person review the code before testing and moving to production.

• No developer or administrator should have access to the Signon PeopleCode setup page, or the records that contain the Signon PeopleCode functions in a production system.

Note. The password that the user types on the signon page is never visible to the Signon PeopleCode developer. It is impossible to write a script that captures a password entered by a user, and store it in a file or database table.

Page Used to Develop Signon PeopleCode

Modifying Signon PeopleCode

Signon PeopleCode is record PeopleCode, which you view and edit on the record with which the program is associated. PeopleSoft applications deliver a PeopleCode program for directory authentication. It is intended for production use but it can also be used as a sample that shows many of the technologies you can include within a Signon PeopleCode program. You can find the delivered PeopleCode program on the following record: FUNCLIB_LDAP.LDAPAUTH (FieldDefault). You can customize it as needed for testing or production use.

Open the record in PeopleSoft Application Designer, and view the PeopleCode with the PeopleCode Editor. The delivered PeopleCode accommodates as many different directory scenarios as possible; it demonstrates use of the business interlink and component interface technologies. You may want to modify the authentication PeopleCode to improve login performance or to accommodate any special directory authentication needs. The delivered program that ships with PeopleTools has the following general flow:

1. Searches the directory server for the user profile of the user signing in.

2. Using the password the user entered at the signon page, the program attempts to bind (or connect) to the directory server.

   If the connect succeeds, then the password is valid.

3. Retrieves the user profile of the user signing in.

   The program gets the profile from the directory server and creates a local cache copy within the PeopleSoft database. This improves performance by enabling the PeopleSoft applications to access the user profile locally, rather than making a call to the LDAP server every time they need user profile data. If a locally cached copy already exists for the user signing in, the local cache is updated according to the current user in the directory server.

Note. To see what the Signon PeopleCode program does, use the PeopleCode debugger. This enables you to step through the program step-by-step.

The following table presents the key PeopleCode constructs that you use with Signon PeopleCode. Click the function to view more details in the PeopleCode PeopleBooks:

Note. Do not use the %SwitchUser variable in Signon PeopleCode.

Enabling Signon PeopleCode

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

Signon PeopleCode is different from other PeopleCode in that you specify which Signon PeopleCode you want to have on a specific Signon PeopleCode page. Notice that the PeopleSoft Password Controls program, which is written in PeopleCode, is also on this page.

By default, some of the Signon PeopleCode programs are disabled. You enable them on this page. You can also enable them by enabling password controls on the Password Controls page or by enabling directory authentication on the Directory Authentication component. After enabling each option on the appropriate page, the system enables the associated PeopleCode program on the Signon PeopleCode page.

Note. Using PeopleSoft password controls is valid only if you are not using LDAP authentication. When you're using LDAP authentication, the directory server, not PeopleSoft, controls the password.

You can add your own PeopleCode programs, but you must add them to another record, and then add them to this page. You add and remove rows from the grid using the plus and minus buttons.

Accessing X.509 Certificates

X.509 certificates are used to authenticate a user at the web server level—SSL/TLS with client-side authentication. You can use PeopleCode to access X.509 certificates.

When you use certificate authentication with PeopleSoft, users do not see the PeopleSoft signon page and enter a user ID. Because of this, the X.509 certificate needs to be available in the Signon PeopleCode so you can write PeopleCode that maps the certificate to a PeopleSoft user ID.

The following sample PeopleCode shows how you access X.509 certificates in Signon PeopleCode:

Local string &clientDN;
&clientDN = %Request.GetParameter("com.peoplesoft.tools.ssl_client_dn");

The value of &clientDN might be similar to the following:

E=tom_sawyer@peoplesoft.com, C=US, S=California, L=Pleasanton,⇒
 O=PeopleSoft, OU=PeopleTools, CN=Tom Sawyer

Using the Web Server Security Exit

This section provides an overview of the web server security exit and discusses how to:

• Create a public access user.

• Modify the web profile.

• Write a Signon PeopleCode program.

• Sign in through the web server.

Understanding the Web Server Security Exit

Part of the integration technology PeopleSoft delivers is to ensure that our security or authentication system is open and flexible. Because the PeopleSoft applications are now designed for internet deployment, many sites must take advantage of the authentication services that exist at the web server level.

Note. The exits described here are offered in addition to the Signon PeopleCode running on the application server, which itself provides integration. There are no PeopleSoft user ("psuser") exits on the application server; Signon PeopleCode replaces that functionality. On the client side, the functionality is the same as previous releases. You should use Signon PeopleCode when developing new signon integration. The topics in this section support previous implementations.

This section describes a procedure that enables you to configure your implementation so that PeopleTools authentication logic "trusts" the authentication performed at the web server level. The following list presents examples of some of the third-party authentication technologies with which you may want to integrate:

• Web single signon or authorization or authentication solutions.

• Client-side SSL/TLS authentication provided by web servers.

• Public Key Infrastructures, either stand-alone or embedded as part of the network operating system environment.

Note. The previous list is not a list of certified integration points, just examples of authentication technologies that exist in the industry.

For the web server exit configuration to work successfully, the following assumptions should be true:

• You want to authenticate the user at the web server level only, not within the PeopleSoft application server.

  (The configuration discussed in this section enables you to authenticate users within the web server instead of the default configuration, where the application server controls the authentication logic.)

• Your web server environment includes a mechanism to identify and authenticate a user.

  This may be through a sign in page with a user ID and password, through a digital certificate, or through one of several industry-standard authentication methods.

• Your web server has the capability of passing the user ID to the application server through the HTTP request PeopleCode object.

  For this you can use an HTTP header variable, a cookie, or a form field.

Note. Configuring the following authentication system is not a delivered feature. It requires development outside of your PeopleSoft application, and because of that, you should have the appropriate level of internet development expertise to make sure that you are passing the appropriate information to the PeopleSoft system.

Creating a Public Access User

You create a public or default user profile by using PeopleTools Security. This user profile does not require any roles or permission lists. You should consider creating a long password that is difficult to guess.

For this example, we create the a user profile with these parameters:

• User ID: PUBUSER

• Password: ekdJl3838**&^^%kdjflsdkjfJHJIK

See Working With User Profiles.

Modifying the Web Profile

After you create the default user, you can modify the web profile to include the default user sign in information.

To modify the web profile to include the default user sign in information, you first must enable public access to the portal. In the Public Users section of the Web Profile Configuration - Security page, select Allow Public Access to indicate that the system should not prompt users to sign in when they click a direct link to a page. When this is selected, the PeopleSoft system does not display the password page to the user. Instead, the system authenticates users with the values specified in the User ID and Password fields in the same section of the page.

Note. In the following discussion, notice that the user is never actually signed in as “PUBUSER.” The user ID you specify is just a temporary value used to initiate a secure connection to the application server. The application server then determines the correct user ID using Signon PeopleCode. The correct user ID is contained in the request object, and all the other user information, such as language code, roles, and so on, is already stored in the PeopleSoft system or an LDAP directory server.

Besides selecting the Allow Public Access check box, you also must set the user ID and password parameters to reflect the user ID created in the previous step. For example, set the User ID field value to PUBUSER, and the Password field to ekdJl3838**&^^%kdjflsdkjfJHJIK.

Because you hard-code the signon values in the web profile, no end user ever needs to know them—their use is transparent.

You should limit access to and knowledge of the public access user ID and password values. You can do this by sharing this information only with a small number of trusted security administrators. Also, you should make sure that only these select few have read access to the web profile.

Even if somebody does discover the public access user ID and password values, he or she won't be able to sign in to the PeopleSoft system. Recall that the PUBUSER doesn't have any roles or permission lists. Alternatively, a sophisticated hacker could attack the application server directly by sending it a connection request formatted in the Oracle Tuxedo/Jolt protocol and potentially assume the identity of a user. You should use network and firewall products to restrict the origin of requests sent to the application server.

Note. To prevent a user ID from being the default user on the sign in page, set the Days to Autofill User ID property on the Web Profile Configuration - Security page to 0.

See Also

Configuring Web Profiles

Writing a Signon PeopleCode Program

In addition to creating a default user and enabling public access, you also must write a Signon PeopleCode program that:

• Uses data within the HTTP request to determine the real user ID.

  Your web server authentication system should be configured to insert the USERID of an authenticated user into the HTTP request as a header, a form field, or cookie.

• Creates or updates the local copy of the user profile within the PeopleSoft database.

The programs developed to perform this task vary depending on where the web server inserted the user ID in the HTTP request and where the user profiles are stored. For example, some systems use an HTTP header to store the user ID, while others use cookies or form fields.

If the web server security product uses LDAP as a backend data store for user profiles, you can reuse some of the LDAP authentication PeopleCode to copy the profile from LDAP to the local database. The user profile may also be stored in another database, or a Windows domain registry. In either case, you must write PeopleCode to retrieve the value and make a local copy.

Note. You can’t use the LDAP Authentication PeopleCode program as delivered. This program performs LDAP authentication and copies the user profile from an LDAP directory to the local database. You can, however, use the code that copies the profile from the directory, as a template for the code you need in this case.

The following is sample PeopleCode with the External_Authentication function. It is a simple example of retrieving the user ID from a form field named UserID:

/*//////////////////////////////////////////////*/
Function External_Authentication()
   
   /*  This application server "trusts" the authentication⇒
 performed by the web server */
   /*  retrieve the USERID from the HTTP request⇒
 and pass it to SetAuthentication Result */
   
   &UserID = %Request.GetParameter("UserID");
   SetAuthenticationResult( True, &UserID, "", False);
   
End-Function;

After you have written the program, you must set the Signon PeopleCode program to run only if authentication is successful. On the Signon PeopleCode page, you set the running as follows:

• Clear the Exec Auth Fail check box; it must not be selected.

  You want this PeopleCode to run only if the connection to the application server originates from a web server that presents a valid user ID and password. In this case, the user ID is PUBUSER and the associated password. You should only select the Exec Auth Fail check box when the PeopleCode itself authenticates the user, not when the program relies on the web server to perform authentication.

• You must set Invoke as to a user profile that has the appropriate roles and permissions to do all the operations in the External_Authentication function.

  For example, if External_Authentication creates a local copy of the user profile using the User Profile component interface, signon_peoplecode_user must have permission to use this component interface. The Signon PeopleCode program runs under the signon_peoplecode_user user ID.

Note. Before running the PeopleCode, the application server authenticates the User ID and Password field values in the Public Users section of the Web Profile Configuration - Security page.

Signing In Through the Web Server

This section provides a step-by-step example of the steps that occur within the system after you have it configured to trust authentication performed at the web server level:

SetAuthenticationResult(True,
"TSAWYER"," ", False);

Using the Windows Security Exit

This section provides an overview of Windows security exits and discusses how to:

• Customize PSUSER.DLL.

• Implement a customized PSUSER.DLL.

Understanding Windows Security Exits

Almost all end users will access PeopleSoft applications by using a browser, so you may not need to implement any client-side Windows exits. However, you can provide this functionality, perhaps for developers.

The Windows client-side exits are:

• PsGetTuxConnectInfo(): Used only for three-tier Microsoft Windows workstations running PeopleSoft Application Designer or Query, for example.

• PsGetLogonInfo(): Used for Microsoft Windows workstations in both a two-tier and three-tier environment.

Use these functions to create a customized PSUSER.DLL. These exits are used primarily for the PeopleTools Development Environment, PeopleSoft Query users, or PeopleSoft Tree Manager users. Unless you intend to deploy PeopleSoft applications to Microsoft Windows workstations, these exits are seldom used.

PsGetLogonInfo was used for the Microsoft Windows Client in previous releases to fill in the signon screen programmatically without displaying it to the user.

With the three-tier Microsoft Windows Client signon you can also bypass the PeopleSoft Signon window by modifying the PsGetLogonInfo() function as with the two-tier connection. But because you are connecting to the database through Tuxedo, there are some other authorizations that need to occur. This diagram shows those authorizations:

Microsoft Windows Client three-tier signon exits

The required authorizations are as follows:

1. The PsGetLogonInfo function must specify APPSERV as the szDBType parameter to bypass the PeopleSoft Signon dialog box.

2. To connect to the Tuxedo application server, the PsGetTuxConnectInfo function retrieves authentication information from directory server.

3. If the authentication information is valid, Tuxedo allows connection.

4. Tuxedo must connect to the database server.

   The application server verifies the authentication information passed by the PsGetTuxConnectInfo function.

5. If the authentication is successful, the user is connected to PeopleTools.

The following diagram illustrates the results produced by customizing the PSUSER.DLL PsGetLogonInfo function to bypass the PeopleSoft Signon dialog box:

Two-tier Microsoft Windows Client signon using PsGetLogonInfo

In this case, the sequence of events is as follows:

1. From the workstation the user runs PSTOOLS.EXE. PSTOOLS.EXE calls the PSUSER.DLL.

2. The PsGetLogonInfo function supplies user signon information.

   If information is validated by the RDBMS, the user is connected as User ID or Connect ID, and then after the security profile is retrieved and validated the user is connected as Access ID.

3. If the signon information is valid, the PeopleSoft system connects the user to the specified PeopleTool.

Customizing PSUSER.DLL

If your site has implemented a security system external to the PeopleSoft system, you can use that external system to validate your Microsoft Windows Client PeopleSoft users, also. This is done through the user exit (PSUSER.DLL), which also enables you to specify your own encryption for use in encrypting passwords.

To enable these options, you must modify several procedures in the PSUSER.C, and recompile to create a new PSUSER.DLL. Then you must install the new DLL file wherever users run the PeopleSoft executable files, such as <PS_HOME> on the file server.

In this section, we discuss the security functions that we provide and how you can tailor them for use in your own system. To successfully complete any customizations with these functions, you must be familiar with the C programming language.

PsGetLogonInfo

The PsGetLogonInfo function is always called when the PeopleSoft system is started. If you’re already controlling which users can access the PeopleSoft applications—through a custom security solution—you may want to use this function to let those users start the PeopleSoft system directly without being prompted for PeopleSoft signon information. This function can also be overridden to provide information to the three-tier exit, PSGetTuxConnectInfo.

As delivered, PsGetLogonInfo returns a FALSE value and is ignored. However, if it returns a TRUE value, the PeopleSoft signon dialog box is bypassed and the information that you’ve coded into the function is used as the signon parameters.

You’ll find this function in your PS_HOME\src\PSUSER\PSUSER.C file. The code initially looks like this:

/*****************************************************
* Function:     PsGetLogonInfo                                         *
*                                                                      *
* Description:  Sample routine to get logon information.               *
*                                                                      *
* Returns:      TRUE if logon information returned                     *
*               FALSE to ignore                                        *
*****************************************************/

PS_EXPORT(BOOL) PsGetLogonInfo(LPPSLOGINFO lpPsLogInfo)
{

/*--------------- BEGIN SAMPLE CODE -----------------

// ask for user input only when it is the first signon
if (!lpPsLogInfo->bSubsequentSignon)
    {
    // test auto logon
    strcpy(lpPsLogInfo->szDBChange, "NO");
    strcpy(lpPsLogInfo->szDBType, "DB2");
    strcpy(lpPsLogInfo->szDBName, "C9442A");
    strcpy(lpPsLogInfo->szServerLogonSec, "NO");
    strcpy(lpPsLogInfo->szOprId, "C944201");
    strcpy(lpPsLogInfo->szOprPswd, "C944201");
    return(TRUE);
    }

------------------ END SAMPLE CODE ----------------*/

return(FALSE);

}

To activate the automated signon feature, you must comment out the “false” return and uncomment the “true” return line. The return value is historical and ignored. The user exit bypasses the screen only if it receives enough information.

Then you must code the appropriate logic to fill in the values for the parameters to the PSGetLogonInfo routine. If you provide all of the appropriate field values, the system proceeds directly to your default initial window specified in the PeopleSoft Configuration Manager Startup tab. Your procedure might look something like this:

PS_EXPORT(BOOL) PsGetLogonInfo(LPPSLOGINFO lpPsLogInfo)
{
/* test auto logon */
//strcpy(lpPsLogInfo->szDBChange, "NO");
strcpy(lpPsLogInfo->szDBType, "ORACLE");
strcpy(lpPsLogInfo->szDBName, "PSORADB");
strcpy(lpPsLogInfo->szServerLogonSec, "NO");
strcpy(lpPsLogInfo->szOprId, "MGR2");
strcpy(lpPsLogInfo->szOprPswd, "password");
return(TRUE);

//return(FALSE);
}

Note. If any required signon parameters are omitted, the signon screen appears and the missing values are set by default to the settings found in the registry. One way to control whether the signon dialog displays is to have PSUSER.DLL provide (or not provide) the user's password.

All parameters except bSubsequentSignon, which is Boolean, are of the data type CHAR and are defined as follows:

PsGetTuxConnectInfo

When operating in three-tier mode, PsGetTuxConnectInfo is called after PsGetLogonInfo and just before connecting to Tuxedo. Use this function to pass authentication data (key) to the server. Use this to either supplement or replace PeopleSoft’s standard authentication process.

You’ll find this function in your PS_HOME\src\PSUSER\PSUSER.C file. The delivered code looks like this:

/******************************************************************
* Function:     PsGetTuxConnectInfo                                    *
*                                                                      *
* Description:  This function is called from PeopleTools just prior to *
*               connecting to Tuxedo.  The PeopleTools client sends    *
*               the data in *ppData to the PeopleSoft Tuxedo           *
*               authentication service (PSAUTH), where it can be used  *
*               as an alternative or supplement to the default         *
*               PeopleTools authentication (see PsTuxAuthExit in       *
*               pssite.c).                                             *
*                                                                      *
* TO DO:        Add logic to obtain client authentication information. *
*               An example might be NT or DCE signon information.      *
*                                                                      *
* Returns:      TRUE if logon information returned                     *
*               FALSE to ignore                                        *
*******************************************************************/

PS_EXPORT(BOOL) PsGetTuxConnectInfo(NETEXTAUTH *pExtAuth)
{

/*------------------------ BEGIN SAMPLE CODE ---------------------------

// set the auth information size and allocate space for auth information
pExtAuth->nLen = 25;
pExtAuth->pData = (unsigned char *) malloc(pExtAuth->nLen);

// set your authentication string
memcpy(pExtAuth->pData, "NATHAN HORNE\0\0PEOPLESOFT\0", pExtAuth->nLen);

return(TRUE);

--------------------------- END SAMPLE CODE --------------------------*/

return(FALSE);

}

Implementing a Customized PSUSER.DLL

To rebuild and implement PSUSER.DLL:

1. Compile PSUSER.C and create PSUSER.DLL.

   To do this for Windows platforms, run NMAKE while in the PS_HOME\src\PSUSER\WINX86 directory. You must use a Microsoft Visual C++ 6.x compiler.

   On UNIX, run the shell script psuser.sh in pshome\src\psuser.

   The resulting file, PSUSER.DLL, is used by PeopleTools (PSTOOLS.EXE), and the Windows COBOL interfaces. For Windows NT, you must copy this file into your COBOL directory.

2. Distribute PSUSER.DLL to workstations.

If your workstations run the PeopleSoft executable files from a common file server, you must ensure that your new PSUSER.DLL is copied to that file server. If any of your workstations run the PeopleSoft executable files locally, PSUSER.DLL must be distributed to such workstations.