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

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.

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.

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.

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.

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.

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.

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.

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);