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.

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.

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.

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.

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

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.

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:






The user clicks a link to the PeopleSoft application, for example http://serverXYZ/servlets/psportal/peoplesoft8/?cmd=start.


Web server

The web server receives the request for the uniform resource locator, authenticates the user, and adds the user ID to the HTTP request for the resource.

The method the system uses to authenticate the user and the method the web server uses to add the user ID to the HTTP request depends on your implementation. For example, it could be a third-party web single signon or authorization solution, a PKI/ digital certificate, or SSL/TLS with client-side authentication.



The PeopleSoft servlet receives the HTTP request, which includes the user ID in a header, cookie, or form field, and connects to the application server using the public user ID and password from the web profile.


Application server

The application server authenticates the connection from the web server by checking the public access user ID and password against the values stored in PSOPRDEFN. The user ID and password must be valid for the connection to succeed and for Signon PeopleCode to run.

Note: The password verification prevents a sophisticated hacker from connecting to the application server directly and carrying out service requests.


Signon PeopleCode

Signon PeopleCode runs, under the context of the signon_peoplecode_user, with all the permissions of this user. It grabs the "real" user ID from the HTTP request and creates a copy of the user profile in the local database (if appropriate). It also calls the PeopleCode built-in SetAuthenticationResult and passes the user ID, and an AuthResult of "true." The PeopleCode program always passes "true" for AuthResult because the application server is "trusting" the authentication logic of the web server.

The Pure Internet Architecture session is set to the user ID of whatever you pass into SetAuthenticationResult. For example:

"TSAWYER"," ", False);

In this case, the system sets the session to TSAWYER. The user can access all the pages to which TSAWYER has access.