11

How PeopleSoft Single Signon Works?

Single Signon refers to the ability of users to navigate freely within a system of multiple applications after only being authenticated once.

It means that user will be asked for his/her login details only once and whenever he/she clicks on a link pointing to other application, then security information is passed from one application to other automatically and there is no additional burden on user to enter login details again. Of course, all these participating application should have Single Signon configured.

Oracle PeopleSoft application can be configured to participate in Single Signon and there are 3 options available:

1. PeopleSoft Only  [PS_TOKEN Cookie]
2. PeopleSoft and Oracle Apps
3. PeopleSoft and Kerberos

In this post, we will discuss about ‘PeopleSoft Only’ Single Signon Implementation and how 2 PeopleSoft applications participate in a Single Signon Setup.

Before we start with the functionality and setup of Single Signon, we should learn a little bit about PS_TOKEN cookie.

What is PS_TOKEN cookie?

PS_TOKEN is a cookie which is embedded into the browser memory of a user authenticated by the PeopleSoft Web Server. As long as cookie is active, user can browse that PeopleSoft Application without entering login details again.

Note: If cookies are disabled in your browser, user won’t be able to get into PeopleSoft Application.

How is PS_TOKEN cookie generated?

When a user enters his/her login details in PeopleSoft application, Webserver passes that information to PeopleSoft Application Server. Based on the information provided, PeopleSoft Application Server performs following tasks:

• Authenticates the user
• Generates a Single Signon Token
• Encrypts the Single Signon Token
• Sends the token to Webserver with a code indicating that system authenticated the user

Single Signon Token generated by Application Server contains user id, language code, date and time when issued , issuing system and the signature.

Signature is created after encrypting the combination of first 4 values and local node password.

Signature = SHA1_Hash ( User ID + Language Code + Date and Time Issued + Issuing System + Local Node Password )

After receiving Single Signon Token from the application server, PeopleSoft Web server generates the PS_TOKEN cookie and then inserts it into user’s browser memory.  Data value of the PS_TOKEN cookie contains the Single Signon Token generated by the Application Server.

 

PS_TOKEN cookie remains in the user’s browser until the session expires.

How Secure is PS_TOKEN Cookie?

PS_TOKEN cookie authentication is considered to be very secure and has few security features.

• PS_TOKEN cookie resides in browser memory and never written to disk
• No Passwords are stored in the cookie
• Encrypted
• Contains Digital Signature
• Cookie becomes invalid after set expiration time

There are few security concerns related to encryption and non-standard algorithm used in generating PS_COOKIE  which may lead a hacker to forge PS_TOKEN. You can read more about it in this article.

How PeopleSoft Only Single Signon Works?

Now that you understand the generation of PS_TOKEN cookie, lets focus on Single Signon process between 2 PeopleSoft Applications. Consider 2 applications to be HCM and FSCM where user first logged into HCM (which will generate PS_TOKEN).

While browsing through HCM application when user clicks on a link pointing to FSCM application, below is series of steps that will occur:

1. Browser sends the PS_TOKEN cookie(generated by HCM) to FSCM Web Server.
2. FSCM Webserver sees signon token and doesn’t display sign in page , instead it sends the DATA field of PS_TOKEN cookie to FSCM application server for authentication and validation.
3. FSCM application server performs the validation checks on DATA field of PS_TOKEN cookie.
   Check 1:  Is forwarding node trusted ? – Issuing system value in the DATA field should be a trusted node in FSCM application with an entry in PSTRUSTNODES table.
   Check 2: Has Token Expired? – Checks Issued Date and Time Value to see if the token has expired. Expiration value set in FSCM is checked instead of value set by HCM application. If HCM has a expiration value of 40 minutes and FSCM has a expiration value of 20 minutes, then value set under FSCM (20) is considered for this validation check.
   Check 3: Signature Tampered? – Using the info in the token, FSCM app server generates a signature and then matches it with the signature present in the token. Both needs to be a perfect match.
4. After all the validation checks are passed, FSCM application server provides the information requested by the user.