PeopleSoft Authentication Process

Before discussing how your pagelet could leverage PeopleSoft authentication, you need to understand the authentication process.

After the first application server or node authenticates a user, the PeopleSoft application delivers a web browser cookie containing an authentication token. PeopleSoft Pure Internet Architecture uses web browser cookies to store a unique access token for all users after they are initially authenticated. When the user connects to another PeopleSoft application server/node, the second application server uses the token in the browser cookie to reauthenticate the user in the background so that they do not have to complete the sign-in process again. Your non-PeopleSoft application could do something similar.

Single signon is critical for PeopleSoft portal implementations because the portal integrates content from various data sources and application servers and presents them in a unified interface. When users sign in through the portal, they always take advantage of single signon. Users need to sign in once and be able to navigate freely without encountering numerous sign-in screens.

The following table presents the fields that appear in the PeopleSoft authentication token.

Field Description

User ID

Contains the user ID of the user to which the server issued the token. When the browser submits this token for single sign-on, this is the user that the application server signs in to the system.

Language Code

Specifies the language code of the user. When the system uses this token for single sign-on, it sets the language code for the session based on this value.

Date and Time Issued

Specifies the date and time that the token was first issued. The system uses this field to enforce a time-out interval for the single sign-on token. Any application server that accepts tokens for sign-in has a time-out minutes parameter configured at the system level.

A system administrator sets this parameter using the Single Signon page. The value is in Greenwich Mean Time (GMT), so the application server’s time zone is irrelevant.

Issuing System

Specifies the name of the system that issued the token. When it creates the token, the application server retrieves this value from the database. Specifically, it retrieves the defined local node. Single sign-on is not related to PeopleSoft Integration Broker messaging, except that single sign-on functionality leverages the messaging concept of nodes and local nodes.

You configure only a node to trust single sign-on tokens from specific nodes. Consequently, an application server needs an Issuing System value so that it can check against its list of trusted nodes to determine whether it trusts the issued token.

Signature

Contains a digital signature that enables the application server using a token for single sign-on to ensure that the token hasn't been tampered with after it was originally issued. The system issuing the token generates the signature by concatenating the contents of the token (all of the fields that appear in this table) with the message node password for the local node. The system then hashes the resulting string using the SHA1 hash algorithm for example,

signature = SHA1_Hash ( UserID + Lang + Date Time issued + Issuing System + Local Node Pswd )

Note: The "+" indicates concatenation.

Only one way is available to derive the 160 bits of data that make up the signature, and that is by hashing exactly the same user ID, language, date time, issuing system, and node password.

Note: If you are using digital certificate authentication, the signature of the digital certificate occupies this space. The preceding description applies only to using password authentication.

Note:

Single signon does not depend on the use of an LDAP (Lightweight Directory Access Protocol) directory. You can store user credentials in an LDAP directory if desired, but it is not required.

These are the key security features of the cookie authentication token:

  • The cookie exists in memory; it is not written to disk.

  • No password is stored in the cookie.

  • You can set the expiration of the cookie to be a matter of minutes or hours. This expiration option is a useful security feature.

  • The cookie is encrypted and digitally signed using a checksum to prevent tampering.