Understanding PeopleSoft-Only Single Signon

PeopleSoft applications supports single signon among other PeopleSoft applications. Within the context of your PeopleSoft system, single signon means that after a user has been authenticated by one PeopleSoft application server, then that user can access other PeopleSoft application servers without entering an ID or a password. Although the user is actually accessing different applications and databases—recall that each suite of PeopleSoft applications, such as HCM or CRM, resides in its own database—the user navigates seamlessly through the system.

Note:

The PeopleSoft-only single signon solution applies only to PeopleSoft applications. Single signon requires that user profiles exist in all databases involved in single signon.

The user profiles to utilize single signon must be defined on all participating databases. For example, for user Marcia Brady to be able to use single signon to access Database A, Database B, and Database C, her user profile must be defined in each of the three databases.

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 the users sign in through the portal, they always take advantage of single signon. Users need to signon once and be able to navigate freely without encountering numerous signon screens. Because single signon is so integral to the portal, you always need to configure it before deploying a live portal solution.

Authentication Token (PS_TOKEN)

After the first application server/node authenticates a user, the system delivers a web browser cookie containing an authentication token (PS_TOKEN). PeopleSoft uses web browser cookies to store a unique access token for each user after they are authenticated initially. When the user connects to another PeopleSoft application server/node, the second application server uses the token in the browser cookie (as long as the token is valid) to re-authenticate users automatically so they don’t have to sign in repeatedly.

Note:

The browser cookie is an in-memory cookie and is never written to disk. The cookie is also encrypted to prevent snooping and digitally signed to prevent tampering.

Check Token IDs

A check token ID verifies that the PS Token is still valid at the originator site or at the last site visited.

Each PeopleSoft database participating in single signon must define a check token ID on the default local node definition on the local database, as well as define the check token ID of their single signon participants on the remote node definitions of each.

You can create a system-generated check token ID by using the Create CheckTokenID button on the Nodes - Node Definitions page. When you click the button, the system generates a random 184 byte/248 character value and populates the value in the Check TokenID field. Note that the Create CheckTokenID button appears only on the Nodes - Node Definitions page for the local default node. As an alternative you can create your own custom check token ID. Custom check token IDs have a 254-character limit. Be sure to copy the ID before saving the component. You must provide this value to your single-signon participants, as they must define this value on their local database on the remote node definition that represents your database. Once you save the component, a mask appears in the field.

See the section “Defining Nodes for Single Signon” later in this section for more information.